1.8 异常处理都有哪些陷阱

本文内容是极客时间课程——代码精进之路中代码规范篇的学习笔记。

 

1.异常状况的处理会让代码的效率变低，正常的情况一定要与异常的情况分清，不能混用。

 

2.异常的分类

（1）非正常异常（Error）

（2）运行时异常（RuntimeException）

接口文档注释中要记录清楚

（3）非运行时异常

 

3.对于三种异常的处理

 

4.如果一个方法既没有异常的声明，又没有异常的规范描述，调用者一般不会进行异常处理，也不在规范描述中加入抛出异常的描述。这样的层次结构，只要稍微多个一两层，运行时异常虽然在代码和规范描述层面消失得无影无踪，但它并没有真正消失，依然会在运行时准时出现。

即使调用者拥有源代码，可以阅读源代码，也不容易意识到有运行时异常需要谨慎对待。代码的阅读者也不会有足够的精力和动力去深挖所有的层次，来确认有没有运行时异常。

 

5.对于代码可能出现异常情况的处理

（1）对于所有的可能抛出运行时异常，都要有清晰的描述，一个也不要错过；

（2）查看所有的调用方法的规范描述，确认抛出的异常要么已经处理，要么已经规范描述。

 

6.Java异常的4个要素

（1）异常类名（IllegalArgumentException，FileNotFoundException）

（2）异常描述（"Invalid file path"）

（3）异常堆栈（at sun.security.ssl.InputRecord.read(InputRecord.java:504)）

（4）异常转换（Caused by: javax.net.ssl.SSLException: Unrecognized SSL message,plaintext connnection?）

 

7.异常使用需要3个注意事项

（1）对于异常类名，我们要准确地选择异常类。

（2）对于异常描述，我们要清晰地描述异常信息。

（3）对于异常转换，我们要恰当地转换异常场景

随着应用场景的转换，我们还需要转换异常的类型和描述。比如，SQLException这种涉及具体实现细节的异常类就不太适合直接抛给最终的用户应用。用户关心的是商业的逻辑，并不是实现的细节，这就需要我们随着使用场景调整异常。如果一股脑地把所有的异常抛到底，业务逻辑就会很混乱，用户体验很不好。

 

8.异常转换的代价

（1）要编写异常转换的代码

（2）信息的冗余，如果转换场景有两三层，异常打印出来的堆栈信息就会很长，而最有用的信息其实只有最原始的异常。

（3）丢失了转换前的异常信息

除非有明确的需求，我们要尽量保留所有的异常信息以及转换场景。

 

9.异常使用的3个原则

（1）不要使用异常机制处理正常业务逻辑；

（2）异常的使用要符合具体的场景；

（3）具体的异常要在接口规范中声明和标记清楚；