开发人员工具和软件通常不会在错误消息中提供解决方案建议。这对编译器来说是有意义的，因为它们应该准确地告诉你出了什么问题。
有“lint”工具可以提供建议，但是据我所知，很少有开发人员经常甚至根本不使用 lint 工具。
有大量面向开发人员的软件可以很好地为错误消息提供“建议的解决方案”部分。这是 Eclipse 等 IDE 所具有的强大功能之一。但是像 Web 应用程序框架、标准/流行库等软件没有这个有用的功能。
这是否只是缺乏用户友好的设计（可以认为这是不必要的，因为谷歌非常好）还是有充分的理由？您使用的任何编译器、框架、平台是否提供带有解决方案建议的错误消息，如果没有，为什么不提供？
你要看什么？
Error: Null Pointer Exception (suggested solution: Set the object to something).
我的意思是，教育你不是错误编写者的工作。我更喜欢指向确切问题的简单错误消息，因此我自己可以确定这次是什么原因造成的。对我来说，这肯定属于 3rd 方工具的范畴；也许编译器可以为他们提供广泛的上下文来进行分析，但这并不是我真正认为有价值的东西。
我想要从编译器或运行时错误中获得的主要内容是上下文——它发生在哪里以及失败时从哪里调用它。
我认为大多数现代编译器和运行时（Java、Ruby、Go）在那里做得不错，通过行号和堆栈跟踪，您可以找到大多数错误。即使 Javascript 选项越来越好，它也肯定优于旧的“alert()”调试方法。
将建议的解决方案留给 IDE 还不够公平吗？
但我确实同意，我看到的框架/库非常稀疏，错误消息非常少，并且“NullPointerException at line 264”在一些没有源代码的第三方库深处告诉你几乎没有。
如果这是一个问题，我认为它主要限于第三方库。“很好的理由”大概是它是在某人的空闲时间匆忙开发的，并且他们没有将有意义的错误消息放在优先级列表中。
出现的错误很难解决。有很多可能性，正如@silky 指出的那样，有些是无法诊断的。
警告是另一种野兽。在许多情况下，现代编译器使用这些来表示“当你说 Y 时，我认为你的意思是 X；你可能想检查一下。”
编程语言有机会在用户界面方面具有最大的灵活性。你可以让电脑做任何你想做的事。硬币的另一面是，如果你打错了一个字符，它可能不知道你的错误是沿着哪个轴或在哪里犯的。
灵活性较低的系统为解决问题提供了更多机会。如果您在 Lisp 编译器中键入 (abc) 并且它不知道 a 是什么，那么它与许多有效代码行非常接近，以至于它无法准确地建议一个修复。如果您在 COBOL 程序的开头拼错了“IDENTIFICATION DIVISION”，编译器会相对容易地发现错误并帮助您。大多数其他语言介于这些极端之间。
在他们的职业生涯中，程序员倾向于从功能较弱且结构化的语言转向功能更强大且更灵活的语言。（至少，这是我在 Javascript 成为如此热门的新手语言之前所看到的情况。）这意味着他们的纪律提高到能够使用提供强大功能的工具，而无需被告知要做什么。我使用的可以告诉我要修复什么的环境往往是我不喜欢使用的环境。
它与任何其他艺术没有什么不同。看看音乐家、画家、武术家、演员、作家或厨师，甚至学习说西班牙语的人：当他们年轻且缺乏经验时，他们会被置于一个有很多结构的系统中，如果他们犯了错误有人可以很容易地纠正它们。随着他们变得更加熟练，他们需要并且想要的支持越来越少。当他们自己成为专家时，他们根本不需要任何支持，但硬币的另一面是你不能轻易指出什么是对或错。如果你的孩子在线条之外涂色，你可以解释这个问题，但如果毕加索或波洛克画得不好，你会怎么说？或者如果菲利普·格拉斯把一张纸条放在不合适的地方，还是李小龙把他的身体变成了一拳？谁愿意以如此有限的艺术形式工作，以至于世俗的事情是不可能的？如果有人真的想要 COBOL 编译器，它们仍然存在，但更多的人花钱购买糟糕的画作，而不是精湛的按数字颜色打印。
更直接地说，有一个站点ErrorHelp (nee bug.gd)，它可以让您输入错误消息并获得结果，它比 SO 更老，但没有人使用它。我试过了。除非您所处的环境只有一个可能的答案，否则在建议解决方案字典中遇到的简单问题是行不通的，因此在任何创意领域都是完全失败的。
大多数 IDE 都有自己的编译器。这允许他们进行部分编译、代码重构和许多其他技巧。我发现错误消息和建议非常有用。仅仅因为编译器没有在命令行上调用，并不意味着它不是编译器。
（来源：theeggeadventure.com）
