2
编译器应如何报告错误和警告？
我不打算在不久的将来编写编译器。仍然，我对编译器技术以及如何改进这些东西很感兴趣。 从编译语言开始，大多数编译器有两个错误级别：警告和错误，第一个是大多数情况下应修复的非致命性错误，以及表示大多数时间无法生成机器（或字节）的错误。输入的代码。 虽然，这是一个很弱的定义。在某些语言（例如Java）中，如果不使用该@SuppressWarning指令，就无法消除某些警告。而且，Java将某些非致命性问题视为错误（例如，由于我想知道的原因，Java中无法访问的代码会触发错误）。 C＃没有相同的问题，但是确实有一些问题。似乎编译是在多个过程中进行的，并且过程失败会阻止进一步的过程继续执行。因此，通常会严重低估构建失败时获得的错误计数。在一次运行中，它可能表明您有两个错误，但是一旦解决它们，您可能会得到26个新错误。 深入研究C和C ++只是显示了Java和C＃的编译诊断弱点的不良组合（尽管说Java和C＃只是解决了一半的问题可能更准确）。有些警告确实应该是错误的（例如，当并非所有代码路径都返回一个值时），但它们仍然是警告，因为我想，当他们编写标准时，编译器技术还不足以使它们成为此类错误。强制检查。同样，编译器经常检查的内容超出标准所规定的范围，但仍将“标准”警告错误级别用于其他发现。通常，编译器不会立即报告他们可能发现的所有错误；可能需要一些编译才能删除所有这些编译器。更不用说C ++编译器喜欢吐出的隐秘错误， 现在添加了许多构建系统，它们可配置为在编译器发出警告时报告失败，我们只是得到了一个奇怪的组合：并非所有错误都是致命的，但有些警告应该；并非所有警告都是应有的，但有些警告已被明确地压制而没有进一步提及它们的存在；有时所有警告都会变成错误。 非编译语言仍然有糟糕的错误报告。在实际运行代码之前，不会报告Python中的Typos，而且您一次也不会真正引发多个错误，因为脚本在遇到一个错误后便会停止执行。 PHP本身具有许多或多或少的重要错误级别和异常。解析错误一次报告一次，警告通常非常严重，以至于中止您的脚本（但默认情况下不是），通知确实经常显示出严重的逻辑问题，某些错误确实还不足以阻止您的脚本，但仍然这样做，并且像往常一样，在PHP中还有一些很奇怪的东西（为什么我们要为不是真正致命的致命错误需要一个错误级别？E_RECOVERABLE_E_ERROR，我是在和您聊天）。 在我看来，我能想到的编译器错误报告的每个实现都被破坏了。真是太遗憾了，因为所有优秀的程序员都坚持认为正确处理错误非常重要，但却无法获得自己的工具来这样做。 您认为什么是报告编译器错误的正确方法？