Java编译器

Question

Java编译器通常会生成大量错误消息，即使原因是单个错误，如未声明的变量。为什么这个编译器在检测到错误后继续处理源文件，而不是直接停止？

Answer 1

对于大型项目，编译可能相当慢；因此，它为程序员节省了编译器通知他们多个错误的时间，而不必修复一个错误，重新编译，修复另一个错误，重新编译，等等。

诚然，一个错误通常会导致许多编译器错误，但一次报告许多错误通常无伤大雅，即使代码中只有一个“真正”的错误。有时会有不止一个“真正”的错误。

默认情况下，javac会在出现100个错误后放弃编译。如果您确实希望它在发生一个错误后停止，您可以设置命令行参数-Xmaxerrs 1。

对于绝大多数程序员来说，这根本不是问题，因为如果您使用集成开发环境，那么javac报告的错误将在代码编辑器中突出显示，您可以将鼠标悬停在每个突出显示上，以查看该部分代码的错误消息。这使得处理更多的错误消息变得更容易管理。很少需要在命令行上运行javac，然后直接从控制台读取这些错误消息。

Answer 2

这是一个很好的问题。传统上，提供有关尽可能多的错误的简明信息一直是编译器的目标，因为编译成本很高:最初需要机器时间，后来需要人工时间来等待编译器。

有争议的是，硬件的改进使得编译速度如此之快，以至于每次编译器运行都要找到不止一个错误的重要性已经消失了。这是特定于语言的(例如，Python类型检查目前非常慢)，这不是一个争论。

每次编译器运行时报告多个错误是一个很难解决的问题。编译器的所有逻辑都旨在利用输入的严格正确性，以便将其转换为正确的输出。当输入包含错误时，编译器工程师可用的唯一选择是打印错误，然后使用启发式算法“猜测”使输入正确的修复。在编译器设计文献中，这被称为解析器中错误的error recovery。但是语义分析需要类似的技术。

在错误恢复方面，可能会出现很多问题。下面是几个例子：

• 猜测并不能纠正这个错误。编译器再次尝试，然后“发现”一个新的错误，并重复这个过程。这就是导致一个错误的多个消息的原因，称为错误级联。
• The guess修复了眼前的问题，但在其他地方制造了一个问题。例如，可以为未声明的变量猜测a类型，这在以后会导致类型错误，因为猜测不是程序员想要的类型。

其结果是，设计人员倾向于专注于每个错误至少发出一条好消息，而不是太多无用的错误级联。在某种程度上，启发式方法工作得足够好，以便更好地将时间花在其他事情上。考虑到一个稳定的编译器很可能是一个相当老的程序，错误行为往往是根据几年前的开发规范而定制的。