聊聊Exception和Error

在日常编程中，处理好异常是比较考验功底的。理解Throwable、Exception、Error的设计分类，掌握应用广泛的子类，如何自定义异常；理解Java中操作Throwable的语法，如try-catch-finally，throw、throws关键字、try-with-resources、multiple catch等。

注：Exception和Error都继承了Throwable类，在Java中只有Throwable类型的实例才可以被抛出（throw）或者捕获（catch），它是异常处理机制的基本组成类型。

Exception和Error体现了Java平台设计者对不同异常情况的分类。Exception是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。Error是指在正常情况下，不大可能出现的情况，绝大部分的Error都会导致程序（比如JVM自身）处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如OutOfMemoryError之类，都是Error的子类。

Exception又分为可检查（checked）异常和不检查（unchecked）异常，可检查异常在源代码里必须显式地进行捕获处理，这是编译期检查的一部分，可检查异常不兼容functional编程（Lambda/Stream）。前面的不可查的Error，是Throwable不是Exception。不检查异常就是所谓的运行时异常，类似 NullPointerException、ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误，具体根据需要来判断是否需要捕获，并不会在编译期强制要求。

理解下Throw early, catch late原则

在发现问题的时候，第一时间抛出，能够更加清晰地反映问题。

捕获异常后怎么处理？最差的处理方式是“生吞异常”，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的cause信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的（业务）逻辑，往往会更清楚合适的处理方式是什么。

从性能方面理解下Java的异常处理机制

try-catch代码段会产生额外的性能开销，它会影响JVM对代码进行优化，建议仅捕获有必要的代码段，尽量不要一个大的try包住整段的代码；也不要利用异常代替if/else控制代码流程。

Java每实例化一个Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，开销可就不能被忽略了。当服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的Exception也是一种思路。 

对于部分追求极致性能的底层类库，有种方式是尝试创建不进行栈快照的Exception。这样做的前提是创建异常时知道未来是否需要堆栈，小范围或许可能，但是在大规模项目中不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂的微服务分布式系统会大大增加诊断的难度。

Have Fun