问题描述
一旦存在解析树，访问者或听众遍历解析树以进行实际翻译将遇到解析无法知道的错误（例如对不存在的外部实体的引用）。当用户看到源代码中的错误时，他们需要查看解析器生成的错误和这些“语义”错误。
现在，我有一个捕获解析错误的自定义侦听器，然后我有一个完全不同的机制来收集第二遍错误，当我向用户呈现错误时，我将这两个错误源合并到一个错误流中.我很着急，它完成了工作，现在是时候做得更好了。
- 更改我的自定义侦听器以重新格式化解析错误，以便在生成它们时将它们添加到合并的流中。那么合并后的流是所有错误的权威来源。
- 以某种方式能够将语义错误添加到我的客户侦听器接收到的错误流中，例如能够从访问函数内部调用
notifyErrorListener。然后我的自定义错误收集器现在是所有错误的权威来源。
我可以轻松地做 #1，但感觉 #2 是正确的选择，我只是不太明白我是如何做到的。
解决方法
一个答案是，我可以在第二遍中直接调用我的自定义错误侦听器，我可以从 Context 对象中制造足够多的参数来生成对 statusCode 的调用，我的自定义侦听器可以响应该调用。
syntaxError然而......阅读下面的评论已经澄清了一些事情。在这一点上，我认为最正确的做法是为错误消息创建我自己的自定义收集器，然后将自定义错误侦听器和语义错误方法提供给该收集器，解析后继续使用 ANTLR 错误侦听器是错误的结束。