Java 编译器

Question

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

Answer 1

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

的确，一个错误通常会导致许多编译器错误，但是即使代码中只有一个“真正的”错误，一次报告许多错误通常也没有什么坏处。 有时会出现不止一个“真正的”错误。

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

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

Answer 2

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

有争议的是，硬件改进使编译速度如此之快，以至于在每次编译器运行时发现多个错误的重要性已经不复存在。 那是特定于语言的（例如 Python 类型检查目前很慢），这不是 SO 的争论。

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

很多可以go错用错误恢复。 几个例子：

• 猜测并不能纠正错误。 编译器再次尝试并“发现”一个新错误并重复该过程。 这就是导致一个错误出现多条消息的原因，称为错误级联。

• 猜测解决了眼前的问题，但在其他地方产生了问题。 例如，可以为未声明的变量猜测 a 类型，这随后会导致类型错误，因为猜测不是程序员的预期类型。

结果是，设计人员倾向于关注每个错误至少发出一条好消息，而不是过多无用的错误级联。 在某些时候，启发式方法运行良好，因此可以更好地将时间花在其他事情上。 鉴于一个稳定的编译器可能是一个相当古老的程序，错误行为往往是根据几年前的开发规范量身定制的。