关于程序的异常处理常识

***原文网址***：*https://www.jianshu.com/p/93aa1cf26b97*

        <p><b>我们经常发现好些java程序猿在编码过程中忽略对异常的处理，或者对异常随意胡乱处理或随便抛出去不管不顾，毫无章法，为应用代码的维护和问题的处理挖了很多坑，让后来维护跟进应用的人想直接问候你妈的心都有，下面根据我的一些经验为大家聊聊作为Java程序猿必须要懂的一些异常处理的指引。</b><br></p><h3>

一．关于java异常的基础知识

Java异常以Throwable开始，扩展出Error和Exception，而Exception又扩展出RuntimeException等异常，常见异常见下图：

Error是程序代码无法处理的错误，比如OutOfMemoryError、ThreadDeath等。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止退出，其表示程序在运行期间出现了十分严重、不可恢复的错误，应用程序只能中止运行。

Exception分运行时异常和非运行时异常

运行时异常都是RuntimeException类及其子类异常，如NullPointerException、IndexOutOfBoundsException等，这些异常也是不检查异常，程序代码中自行选择捕获处理，也可以不处理。这些异常一般是由程序逻辑错误引起的，程序代码应该从逻辑角度尽可能避免这类异常的发生。所有继承Exception且不是RuntimeException的异常都是检查异常，如上图中的IOException和ClassNotFoundException，编译器会对其作检查，要么在方法体中声明抛出checked Exception，要么使用catch语句捕获checked Exception进行处理，不然不能通过编译。因此java程序猿重点要关注处理运行时异常，下面一些处理异常指引主要针对它而言。

二．业务异常的通常处理机制（可选，局部异常处理）

1.不想处理或未知的异常一直往外抛直至到最上层集中处理，注意集中处理，处理时必须输出对应的日志。

如：利用Sring mvc支持异常集中处理特性

不想处理或未知的异常从dao->service->controller往上抛，然后在controller统一集中处理，当然可按需集中处理，如不处理统一交给全局异常处理。

注意：异常集中处理时不能丢掉或吃掉异常，一定要把异常捕获并后台输出错误日志，但页面上不能输出错误日志，且响应状态码不能设置为200，要按需设置为40x或50x。

2.Jsp页面处理异常

Jsp代码抛出异常并结合errorPage搭配组合使用。如：

新建一个异常接收页面error.jsp，在该页面指定<%@ page isErrorPage="true"%>，然后其他jsp页面的异常处理指向它，<%@ page errorPage="error.jsp"%>

当然可按需处理，如不处理统一给全局异常处理。

注意：error.jsp不能丢掉或吃掉异常，一定要把异常捕获并后台输出错误日志，但页面上不能输出错误日志，且error.jsp的响应状态码不能设置为200，要按需设置为40x或50x。

三．全局异常处理（必须，上面第二步没处理的异常最后统一处理）

通过web.xml配置接收异常的页面

其他http响应状态码按需配置，如400、502、503、504等。

还可按指定异常配置接收异常页面，如：

注意：此异常接收处理页面不能用静态页必须是动态页，且不能丢掉或吃掉异常，一定要把异常捕获并后台输出错误日志，但页面上不能输出错误日志，且异常接收页面的响应状态码不能设置为200，要按需设置为40x或50x。

以上第二和第三部分互为一体，有些异常需要局部处理的按需处理。

三．一些必须及时捕获处理异常的场景

1.用多线程实现的定时任务在循环处理数据时出现异常必须及时处理，否则执行时会退出。

2.页面豆腐块接口或供外接口必须处理异常，如出现异常返回空字符串或其他指定格式的信息提示返回。

3.ajax异步调用的接口必须处理异常，如出现异常返回空字符串或其他指定格式的信息提示返回。

四．一些关于处理异常的重要原则

1.捕获异常是为了处理它，捕获异常后吃掉不作任何处理是毫无节操无人品的耍流氓，至少要输出简单的错误日志提示，如果不想处理它，请将该异常抛给它的调用者。

捕获异常后不处理的代码示例：

try{

Do something;

}catch(Exeception e){

//此处无任何代码处理异常，挖坑作死的节奏！

}

2.异常不要用来做流程或条件控制，因为异常的处理效率比较低。

3.防止出现空指针异常是程序员的基本修养，注意该异常产生的场景。

4.当方法判断出错该返回时应该抛出异常，该抛异常就得抛，而不是返回一些错误值，如返回-1 或者 -2 之类的错误值。

5.如需处理处理异常，其处理的粒度不能太粗，如几百行代码放到一个try-catch 块中处理，应该一个一个异常放在各自的try-catch 块中处理。

6.对于一个应用来说，应该要有自己的一套整体的异常处理机制，当各种异常发生时能得到相应统一的处理风格，将友好的异常信息反馈给用户。

---

文/阿青，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系阿青。