前言

Java异常处理的十个建议，希望对大家有帮助~

本文已上传github:

一、尽量不要使用e.printStackTrace(),而是使用log打印。

反例:

• printStackTrace()打印出的堆栈日志跟业务代码日志是交错混合在一起的，排查异常日志不太方便。
• e.printStackTrace()语句产生的字符串记录的是堆栈信息，如果信息太长太多，字符串常量池所在的内存块没有空间了,即内存满了，那么，用户的请求就卡住啦~

二、catch了异常，但是没有打印出具体的exception，无法更好定位问题

反例：

反例中，并没有把exception出来，到时候排查问题就不好查了啦，到底是SQl写错的异常还是IO异常，还是其他呢？所以应该把exception打印到日志中哦~

三、不要用一个Exception捕捉所有可能的异常

反例：

理由：

• 用基类 Exception 捕捉的所有可能的异常，如果多个层次都这样捕捉，会丢失原始异常的有效信息哦

四、记得使用finally关闭流资源或者直接使用try-with-resource

反例：

需要使用finally关闭流资源，如下

如果不使用finally或者try-with-resource，当程序发生异常，IO资源流没关闭，那么这个IO资源就会被他一直占着，这样别人就没有办法用了，这就造成资源浪费。

五、捕获异常与抛出异常必须是完全匹配，或者捕获异常是抛异常的父类

反例：

虽然一个正常情况都不会发生的异常，但是如果你捕获到它，就不要忽略呀，至少打个日志吧~

理由：

• 我们的项目，一般都会把代码分 Action、Service、Dao 等不同的层次结构，如果你是DAO层处理的异常，尽早处理吧，如果往上 throw SQLException，上层代码就还是要try catch处理啦，这就污染了你的代码~

八、自定义封装异常，不要丢弃原始异常的信息Throwable cause

我们常常会想要在捕获一个异常后抛出另一个异常，并且希望把原始异常的信息保存下来，这被称为异常链。公司的框架提供统一异常处理就用到异常链，我们自定义封装异常，不要丢弃原始异常的信息，否则排查问题就头疼啦

反例：

十、注意异常匹配的顺序，优先捕获具体的异常

注意异常的匹配顺序，因为只有第一个匹配到异常的catch块才会被执行。如果你希望看到，是NumberFormatException异常，就抛出NumberFormatException，如果是IllegalArgumentException就抛出IllegalArgumentException。

反例：

理由：

• 因为NumberFormatException是IllegalArgumentException 的子类，反例中，不管是哪个异常，都会匹配到IllegalArgumentException，就不会再往下执行啦，因此不知道是否是NumberFormatException。所以需要优先捕获具体的异常，把NumberFormatException放前面~