为编程语言设计怎样的错误处理方式才是“好的”？
以下是一些常见的错误处理方式：
1. 异常处理：在程序运行期间发生异常时，抛出一个异常对象并将其传递给堆栈。异常处理器负责捕获异常并采取适当的措施来处理它。这种方式可以提高程序的可靠性和可读性，但是因为异常处理器的开销比较大，可能会影响程序的性能。
2. 返回值：在函数调用中，如果函数返回一个特定的值表示函数执行失败，程序员可以通过检查返回值并采取适当的措施来处理错误。这种方式比较简单，但是可能会导致代码重复和混淆，因为每次函数调用都需要检查返回值。
3. 断言：断言是一种在程序运行时检查某个条件是否为真的方式。如果条件不成立，则程序将中止并显示错误消息。这种方式可以帮助程序员快速发现和解决错误，但是它可能会导致程序的可读性和可维护性下降。
4. 日志记录：在程序运行时，将错误信息记录到日志文件中，以便程序员可以在以后查看并解决错误。这种方式可以帮助程序员诊断和解决错误，但是可能会对程序的性能产生一些影响。
总的来说，一个“好”的错误处理方式应该能够平衡程序的可靠性、可读性和性能。在设计错误处理方式时，需要考虑程序的实际情况和要求，以选择最适合的方式。
## 背景我是搞C++的，当然也会用Java、Go等。我最近连续遇到好几个try-catch导致不知道错误源头的问题。这让我特别烦心。这也促使我最近反复思考，到底计算机编程语言错误处理应该怎么设计才是“好的”？CC的错误处理很原始。就是用全局的错误码或者用返回值或者类似的等价物。对于简单的场景，这个很好使。但对于类似要从很底层向很外层传递一个错误的场景，这种方式的就特别麻烦。基本上没发做好！JavaJava往往被吐槽，一层套一层的try-catch，写起来实在麻烦。一个芝麻大点功能，动不动就是四五个异常要处理。这也导致很多人往往会直接捕捉所有异常了事。C++C++ 可以用C的处理方式，也有Java的异常机制。两种方式都可行，这看起来很完美。但这也意味着C++也有C和Java的错误处理方式的所有缺点。C++的异常不是必须的。你可以随意忽略异常。它的异常机制和错误码是两套独立的机制，还不能同事使用。搞C++ 的同学也容易写出捕获所有异常的代码。导致我前面遇到的问题。真的一言难尽。Gogo有两种错误处理机制，一个是通过返回值返回error对象，这跟C的错误码机制差不多。缺点可想而之，被吐槽N多年了。go还有个panic-recover错误处理机制。这东西初看很简单，但是控制力太弱，约束也多。用得很少。RustOption模式是从Rust大力推广开的。但这也也没解决跨层错误传递的问题 问题编程语言的错误处理，到底应该怎样设计才好？
优秀作者:蓝眼视影