互联网系统可靠性基础：正确的异常处理

互联网系统可靠性基础：正确的异常处理

     系统的可靠性比性能、高并发更重要。没人希望整天分析错误数据、修复错误数据。任何一个错误都可能导致客户的损失。

     成熟可靠的系统和不可靠系统之间的差别很大程度取决于：异常的正确处理。经验丰富的程序员和经验不丰富的程序员之间的差别是是否考虑到并正确处理可能发生的各种异常。这和处理用户输入数据的验证非常相似。

     可以发现即使是运行多年，知名的互联网公司的大型系统都或多或少存在异常处理的问题。

Try catch 的内部实现

这篇文章有比较简单的解释。

异常必然发生

原因很多种：比如，网络不稳定、硬件故障、软件 BUG 等等。很多程序员如果不接触系统运维的话，很难考虑到并处理这些异常。这是问题原因的一部分。从这个角度看全栈工程师还是非常有用的。

异常处理的性能考虑

Donald Knuth: “premature optimization is the root of all evil”.

考虑到这个问题其实就已经进入的误区。该交给编译器的事情还是不要过多考虑了。

应该使用 try catch 的情况

说道 try catch 的性能，可能很多人会想到这会让程序变慢。其实不然，虽然它对应用性能的影响取决于编译器的实现，但是大部分情况下不会影响不抛异常情况下的执行速度，但是会有稍微内存占用的提升。并且，假如异常很少触发，使用 try catch 取代错误码然后 if 判断的方式可以提升速度，因为你不需要没次都判断这个错误码。使用异常代替判断还可以让程序更可读。

不应该使用 try catch 的情况

异常处理不应该取代 if else 用来做流程控制。

几个理念：Fail fast vs Retry vs Let it crash

Let it crash & Fail Fast

可以让错误停止扩散，保证整个系统的健康。可以重置系统状态、清理变量和内存占用等等。让系统恢复到原始状态。这对于恢复系统异常非常有用。

重试 Retry

在操作幂等的情况下，假如第一次操作失败，重试是处理异常的很好的方式。但是注意自动重试在处理不当的情况下会引起操作数量持续增长导致系统雪崩。

异常和错误的类型

第一种划分：

1. 编译错误：很明显，易处理。
2. 应用逻辑错误：最难发现问题；(类型系统有助于避免逻辑错误。Let it crash 主要针对逻辑错误和 BUG。)
3. 运行时错误：终止进程。
4. 生成的异常：throw 异常，尽早发现问题。

第二种划分：

1. 内部异常：可以内部恢复的异常；一般记录日志或打印相关信息告知用户错误。
2. 外部异常：Error，只能从外部恢复；一般打印堆栈信息并退出。还包括 RuntimeException， 软件 BUG，逻辑错误，错误使用 API。比如 NullPointerException。Let it crash 就是主要针对逻辑错误。这需要人工介入及时修复 BUG 。

异常区分的简单原则：

如果应用可以从异常中自动恢复，则为内部异常。如果不能，则为外部异常。