Java异常处理总结

            背景              

最近专门负责团队的项目质量。我在治理异常日志过程中，总结了一下Java的异常处理。上面是我整理的最近自己比较常见的异常知识地图。

  异常知识地图概述  

从异常知识地图最左边的根开始看，地图从左到右的连线连接的类之间有实实在在的父子关系，在java里通过继承来实现（除了非RuntimeException是个虚拟父节点）。

☆Java所有异常的父类是Throwable，它又分为Error和Exception。

☆ Error是程序判定如果执行了XX逻辑，则应该是至少JVM层面出现了问题。正常情况下不应该发生的。

☆ Exception意思是环境没有什么问题，出现Exception请开发人员自己搞定。

☆ Exception分为RuntimeException运行时异常和非运行时异常。

说到这里，我们从另外一个维度给异常分类。Java异常又分为检查异常和非检查异常。Error和RuntimeException以及RuntimeException的子类是非检查异常。其他是检查异常。这个很好区分。在写Java代码的时候，编译器提示需要try catch或者throws的就是检查异常。其他是非检查异常。后面在具体代码实现里有体现。

☆ 异常分为检查异常和非检查异常。                                                   

   典型异常发生场景   

典型异常发生的场景我做了一些demo，上传到了github，地址：

https://github.com/xiexiaojing/yuna

为了方面展示使用一个统一的切面来截获异常：

@RestControllerAdvice
public class ControllerThrowableAdvice {

    @ExceptionHandler(Throwable.class)
    public String handleThrowable(Throwable e) {
        return "ControllerThrowableAdvice消息:" + e.toString();
    }
}

Error

Error及其子类一般不是用来捕获的，而用来抛出的。因为Error的发生意味着环境有问题，该停下来检修了。所以一般的处理是一旦发生Error，会停止JVM。也就是平时看到的程序起不来。如下java.awt.image.Kernel的源码。

Error除了手工抛出，在常用的类库中不用黑科技是不能稳定复现的。所以我测试类是这么写的

@GetMapping("/errorThrowable")public String showErrorThrowable(){ Error error = new Error("人工抛出一个Error"); throw error;}

直接访问页面的结果

ControllerThrowableAdvice消息: 

org.springframework.web.util.NestedServletException:Handler dispatch failed; nested exception is java.lang.Error: 人工抛出一个Error

上面错误消息意思是spring mvc通过其核心逻辑DispatcherServlet没有找到任何一个可以处理这个返回model的，因为直接返回就是一个Error。最后显示的消息通过ControllerThrowableAdvice进行展示。

注意Error是非检查异常，不用显示处理。

NPE

NPE也就是平时说的空指针异常，它非常常见，很多类都没有对null做支持。直到apache提供了common包专门来处理这种情况。防不胜防，时不时项目还是需要为了处理这个异常上线个bugfix。

@GetMapping("/npe")public String showNullPointerException() { new HashSet<String>(null); return prefix + "异常未抛出";}

直接访问页面的结果

ControllerThrowableAdvice消息:java.lang.NullPointerException

这是因为new HashSet的时候传入null。程序走不到return就抛出异常了。最后显示的消息通过ControllerThrowableAdvice进行展示。

注意NullPointerException是非检查异常，不用显示处理。

算数异常

算数异常非常常见，比如做除0，会抛出异常java.lang.ArithmeticException: / by zero，提示我们该找数学老师帮我们检查作业了。值得注意的是如果使用BigDecimal.divide来做除法，请直接使用divide(BigDecimal divisor, int scale, RoundingMode roundingMode)这个传3个参数的，避免

divide(BigDecimal divisor)这个传1个参数的，因为如果传的值除不尽会抛出java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result. 带三个参数的方法会在除不尽的时候按照传入的摄入模式和保留小数点后的位数对数据做处理。

注意ArithmeticException是非检查异常，不用显示处理。

未声明异常

未声明异常代码量稍大，想知道测试源码的直接去我github里下载。

地址：https://github.com/xiexiaojing/yuna

抛出异常的原理是使用动态代理时，如果被代理的类抛出了一个异常。但是却没有throws声明。代理类找不到匹配的异常类型会抛出InvocationTargetException。从知识地图上可以看到它是非检查异常。最后会被UndeclaredThrowableException来处理。这是java动态代理不优雅的处理方式。建议喜欢看源码、模仿源码的朋友对这一点不要借鉴哦。

重点来看一下运行抛出异常的打印堆栈

java.lang.reflect.UndeclaredThrowableException
  at com.sun.proxy.$Proxy17.showException(Unknown Source)
  at com.brmayi.yuna.controller.ExceptionController.showUndeclaredThrowableException(ExceptionController.java:62)
  at com.brmayi.yuna.controller.IndexControllerTest.showUndeclaredThrowableException(IndexControllerTest.java:34)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
  at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
  at org.mockito.internal.runners.DefaultInternalRunner$1$1.evaluate(DefaultInternalRunner.java:44)
  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
  at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
  at org.mockito.internal.runners.DefaultInternalRunner$1.run(DefaultInternalRunner.java:74)
  at org.mockito.internal.runners.DefaultInternalRunner.run(DefaultInternalRunner.java:80)
  at org.mockito.internal.runners.StrictRunner.run(StrictRunner.java:39)
  at org.mockito.junit.MockitoJUnitRunner.run(MockitoJUnitRunner.java:163)
  at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
  at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
  at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
  at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: java.lang.reflect.InvocationTargetException
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at com.brmayi.yuna.util.ObjProxy.invoke(ObjProxy.java:14)
  ... 35 more
Caused by: java.lang.ArithmeticException: / by zero
  at com.brmayi.yuna.service.ShowUndeclaredThrowableExceptionService.showException(ShowUndeclaredThrowableExceptionService.java:5)
  ... 40 more

从打印的堆栈可以看到这个是最终的ArithmeticException抛出时被InvocationTargetException捕获。将原来的参数传给了InvocationTargetException后继续抛出，最后被UndeclaredThrowableException捕获。

注意UndeclaredThrowableException是非检查异常，不用显示处理。

不合法参数异常

不合法参数异常是很多类或者方法自己定义了java基本规则外的一些规则，不满足会抛出的异常。比如java动态代理的源码里就写了被代理的接口不能超过65535个。否则就抛不合法参数异常。

注意IllegalArgumentException是非检查异常，不用显示处理。

以上都说的是非检查异常。下面开始检查异常。由于IO异常很常见好构造，我们直接来看它的子类。

套接字异常

套接字异常在通信编程时非常常见。比如如下代码

 @GetMapping("/socket")
public String showSocketException() throws Exception {
    ServerSocket socket = new ServerSocket(8081);
    socket.close();
    socket.setReuseAddress(true);
    return prefix + "异常未抛出";
}

启动了一个套接口服务端，马上关闭。关闭后才去调用setReuseAddress。这时候就会抛出java.net.SocketException: Socket is closed。

注意SocketException是检查异常，需要显示处理。

绑定异常

    套接字异常有一种情况，可以明确的知道是绑定异常，就不用抛出套接字异常这样模糊的异常了。

@GetMapping("/binding")
public String showBindingException() throws Exception {
    ServerSocket socket = new ServerSocket(80);
    socket.setReuseAddress(true);
    return prefix + "异常未抛出";
}

如上，80端口是http默认端口，不能在自定义通信程序里使用。这时候就会抛出java.net.BindException: Permission denied。

注意BindException是检查异常，需要显示处理。

主机名未知异常

主机名未知异常在比如内网DNS出现问题、或者远程调用时由于机器下线等原因找不到主机时出现。可以人为连接一个未启用的端口来构造。

@GetMapping("/unknownHost")
public String showUnknownHostException() throws Exception {
    new Socket("ttt", 5300);
    return prefix + "异常未抛出";
}

注意UnknownHostException是检查异常，需要显示处理。

超时异常

超时异常因为在分布式系统中涉及程序内部线程间、程序之间的通信多，所以非常常见。具体代码有点长，详见

https://github.com/xiexiaojing/yuna

抛出java.util.concurrent.TimeoutException。它是concurrent包里的一个类。

注意TimeoutException是检查异常，需要显示处理。

反射操作异常及其子类

反射操作异常一般只在启动时看到，线上程序运行中一般不会发生。因为常见类里它是这么处理的

上面可以看到在java.net.InetAddress的源码里，ReflectiveOperationException的处理是直接抛出Error。

在程序启动时，经常会由于maven pom里引入的包冲突、版本不合适、或者是缺少包引起「类找不到异常」。例如下面的测试例子：

@GetMapping("/classNotFound")
public String showClassNotFoundException() throws Exception {
    Class.forName("com.XXX");
    return prefix + "异常未抛出";
}

由于com.XXX不存在。会直接抛出java.lang.ClassNotFoundException: com.XXX。它是反射操作异常的子类。平时反射操作异常及它的子类异常一旦发生就会抛出Error，JVM停止。如下面的源码：

Spring对于异常的处理

默认异常处理

Spring的MVC在默认情况下对不能处理的异常如404、500会抛出白页。像下面这样：

这是因为Spring MVC的核心处理类DispatcherServlet的doDispatch方法包含代码片段：

mappedHandler = getHandler(processedRequest);
// 找到合适的请求处理器
if (mappedHandler == null || mappedHandler.getHandler() == null) {
    // 原则上如果没有找到则会进入到这里，并且设置response的状态码为404
    // 但是经过调试并没有进入到这里
    noHandlerFound(processedRequest, response);
    return;
}

它最终处理是返回/error页。也就是白页。不知道大家有没有注意到我前面在介绍Error的时候，定义了error页面的url地址为errorThrowable。

这是因为error是被Spring自身占用了。如果定义为error，我们将看不到预期的结果，而是下面的白页

这里因为/error是默认页面，返回了999的http错误码，意思是请求被拒绝。

自定义异常处理

在典型异常的发生场景里一开始就介绍了定义了一个统一错误处理如下：

@RestControllerAdvice
public class ControllerThrowableAdvice {

    @ExceptionHandler(Throwable.class)
    public String handleThrowable(Throwable e) {
        return "ControllerThrowableAdvice消息:" + e.toString();
    }
}

这是使用了spring aop做了统一拦截。Advice在AOP的概念中翻译成增强。包括Before、After、Around等增强时机。这里类名用到了Advice意思是在controller发生Throwable时做的增强。看到有的项目喜欢用

@ExceptionHandler(Exception.class)

这个也OK。但是我会假设Everything fails! 程序在发生平时不会遇到的问题时也可控。

              总结               

本文先围绕着异常知识地图介绍了各种异常及出现场景，最后结合Spring论述了在实际工作中如何统一处理异常。这里推荐一个学习方法：梳理知识地图，给地图框架填充内容，让自己的知识体系化。