Java异常处理实践

摘抄自朱晔老师的《Java业务开发常见错误100例》

“统一异常处理”：不在业务代码层面考虑异常处理，仅在框架层面粗犷捕获和处理异常。这中想法是错误的。
基于springMVC三层模型（Controller、Service、Repository）来讲。
从业务性质上异常可以分为业务异常和系统异常。

• Repository层出现异常或许可以忽略，或许可以降级，或许可以转化为一个友好的异常。如果捕获仅记录日志，很可能业务逻辑已经出错，而用户和程序本身完全感知不到。
• Service层往往涉及数据库事务，出现异常同样不适合捕获，否则事务无法自动回滚。有些业务逻辑执行遇到业务异常，可能需要在异常之后转入分支流程。异常被捕获了业务异常可能就会不正常。
• Controller层往往需要给用户友好的提示，或者根据每个api异常表返回指定的异常类型。

所以很难进行统一的异常处理。所以不建议在框架层面进行异常的自动、统一处理，尤其是不要随意捕获异常。但是框架可以做兜底工作，在最外层捕获“未处理”异常。例如使用@RestCOntrollerAdvice+@ExceptionHandler来捕获这个”未处理“的异常

常见错误

错误一：
捕获了异常直接生吞。在任何时候捕获了异常都不应该生吞，也就是直接丢弃异常不记录、不抛出。这样还不如不捕获异常，因为被生吞的异常一旦导致Bug，就很难在程序种找到问题，使得Bug排除难上加难。

catch(IOException e) {
}

错误二：
丢掉异常原始信息。虽然没有完全生吞，但是也丢失了宝贵的异常信息。
错误写法

catch(IOException e) {
    throw new RuntimeException("系统异常")
}

正确写法

catch(IOException e) {
    throw new RuntimeException("系统异常", e)
}

错误三：
抛出异常时不指定任何消息

throw new RuntimeException();

常见的处理方式

• 通过日志正确记录异常原始信息
• 转化，即转化为新的异常抛出。对于新抛出的异常，最好有明确的分类和明确的异常消息，而不是抛出一个无关或者没有任何信息的异常。
• 重试，重试之前的操作。比如远程调用过程。需要考虑是否合适重试
• 恢复，尝试使用降级处理，或使用默认值来替代原始数据。