<p><b>我们经常发现好些java程序猿在编码过程中忽略对异常的处理,或者对异常随意胡乱处理或随便抛出去不管不顾,毫无章法,为应用代码的维护和问题的处理挖了很多坑,让后来维护跟进应用的人想直接问候你妈的心都有,下面根据我的一些经验为大家聊聊作为Java程序猿必须要懂的一些异常处理的指引。</b><br></p><h3>
一.关于java异常的基础知识
Java异常以Throwable开始,扩展出Error和Exception,而Exception又扩展出RuntimeException等异常,常见异常见下图:
![](https://i-blog.csdnimg.cn/blog_migrate/6241580e22e442c3dbb26e22628a145e.png)
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统一集中处理,当然可按需集中处理,如不处理统一交给全局异常处理。
![](https://i-blog.csdnimg.cn/blog_migrate/01054e35f0a59ef23469a4ac00c79a3d.png)
注意:异常集中处理时不能丢掉或吃掉异常,一定要把异常捕获并后台输出错误日志,但页面上不能输出错误日志,且响应状态码不能设置为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配置接收异常的页面
![](https://i-blog.csdnimg.cn/blog_migrate/9f1813e42e72a24668ff299ed36aa5fa.png)
其他http响应状态码按需配置,如400、502、503、504等。
还可按指定异常配置接收异常页面,如:
![](https://i-blog.csdnimg.cn/blog_migrate/feb90297d9df5faab14101364c7725a5.png)
注意:此异常接收处理页面不能用静态页必须是动态页,且不能丢掉或吃掉异常,一定要把异常捕获并后台输出错误日志,但页面上不能输出错误日志,且异常接收页面的响应状态码不能设置为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.对于一个应用来说,应该要有自己的一套整体的异常处理机制,当各种异常发生时能得到相应统一的处理风格,将友好的异常信息反馈给用户。
文/阿青,写代码写诗写职场的程序猿大叔,倾力原创简单实用的硬干货,转载此文请联系阿青。