1、Java异常类型结构

异常机制允许程序员对可能会出问题的代码块提前布置好响应策略，即使异常场景出现也能按照预期的应对措施使程序正常退出，打印相关错误日志或者转移给能处理这个错误场景的处理器。Java异常类型结构如下图所示：

Throwable类是所有异常类的基类，有两个分支：Error和Exception。

Error类描述了Java运行时系统的内部错误和资源耗尽错误，Error的子类比如VirtualMachineError，按照Java惯例，我们是不应该是实现任何新的Error子类的。
Exception类是我们平时接触Java异常类最多的一个体系，继承自Throwable类，下面有两个分支：RuntimeException类和IOExeception类。

RuntimeException类以及其子类是由于程序运行错误导致的异常，如果出现了RuntimeException类，程序肯定是有问题的，常见的RuntimeException类的子类有NullPointerException（空指针异常）和IndexOutOfBoundsException（数组访问越界）等。如果产生运行时异常，则需要通过修改代码来进行避免，比如在程序开头加入：

if (*** is null)
{
   ***
   return;
}
if (Collections.isEmpty(***))
{
   ***
   return;
}

IOException类以及其子类是程序本身没有问题，是由于类似IO错误这类环境问题导致的异常，常见的IOException类的子类有FileNotFoundException（找不到文件异常）等。

Java异常体系除了上面的分类方式外，还有一种分类方式：受查异常（checked）和非受查异常（unchecked）。

受查异常会在编译时被检测，上面提到的IOException以及其子类就是受查异常。此类异常，要么通过throws向调用者抛出，要么通过try-catch子句进行捕获处理，否则不能通过编译。
非受查异常在编译时不会被检测，上面提到的Error和RuntimeException类及其子类就是非受查异常。

2、Java异常处理措施

2.1 自定义异常
除了上面介绍的那些异常类及其子类外，项目里肯定会有自己的一系列跟项目相关的自定义异常类及其子类，通常会有一个项目相关的抽象异常类，然后会针对业务场景实现不同的子类。
这里以继承Exception类实现子类为例，如下：
```
public class MyException extends Exception {
  public MyException()
  {
  }
  public MyException(String message)
  {
      super(message);
  }
}
```
通常自定义一个异常类要有两个构造函数：一个无参构造函数和一个带有详细描述信息的构造函数，构造自定义异常时将具体的错误信息的字符串传入并初始化自定义异常。

2.2 异常的抛出 throws/throw
throws是用于声明抛出的异常，通常在方法声明处，throws后面会跟一系列可能会抛出的异常列表；而throw是用于抛出异常，通常在方法里的catch子句里，结构如下：
```
public void method throws ExceptionA, ExceptionB...
  {
      ...
      throw new ***Exception();
  }
```
2.3 捕获异常 try-catch-finally
结构如下：
```
try
{
  // 执行业务，可能会抛出异常
}
catch (***Exception e)
{
  // handle ***Exception
}
finally
{
  // 释放try块里打开的物理资源
}
```
try
try语句里存放可能会抛出异常的代码块。
catch
catch子句里捕获try语句代码块里抛出的异常，并针对具体的异常分别做相应的处理，比较常见的一种处理手段就是针对具体的异常场景打印相关日志，需要注意的是catch子句里不要吃大异常，即出现catch(Exception e)这种，最好是具体到比较细的异常类，用多个catch子句分别处理。
在一个 try-catch 语句块中可以捕获多个异常类型，并对不同类型的异常做出不同的处理，如下：
```
try {
      ...
  } catch (FileNotFoundException e) {
      // handle FileNotFoundException
  } catch (IOException e){
      // handle IOException
  }
```
同一个 catch子句里也可以捕获多种类型异常，用 | 隔开，如下：
```
try {
      ...
  } catch (FileNotFoundException | UnknownHostException e) {
      // handle FileNotFoundException or UnknownHostException
  } catch (IOException e){
      // handle IOException
  }
```
finally
finally语句总会被执行，finally子句里主要做的事情是回收try子句里建立的物理资源，比如数据库连接池，网络连接等，只有finally子句执行完毕后，才会回过头去执行try子句里的return语句或者catch子句里的 throw语句，注意以下两点：
即使try子句里出现了return语句，finally子句里的代码依然会执行；
如果finally子句和try子句里都有return语句，则仅会执行finally子句里的retrun语句。

完整的异常demo如下：

public class main {
    public static void main(String[] args) {
        // boolean flag = false;
        boolean flag = true;
        try {
            method(flag);
        } catch (MyException e)
        {
            // 模拟异常处理部分
            e.printStackTrace();
        }
        finally {
            System.out.println("这个demo里finally子句什么都不需要做");
        }
    }
    public static void method(boolean flag) throws MyException
    {
        if (flag)
        {
            System.out.println("抛出异常，这里一般是打印日志，demo里打印到控制台");
            throw new MyException("抛出了MyException异常");
        }
        // 否则执行method方法里的业务逻辑
    }
}

当flag置为true，触发method方法里的异常，结果如下：

抛出异常，这里一般是打印日志，demo里打印到控制台
Exception.MyException: 抛出了MyException异常
    at Exception.main.method(main.java:35)
    at Exception.main.main(main.java:19)
这个demo里finally子句什么都不需要做

2.4 try-with-resource

上面提到的finally子句中，会关闭创建的资源，但是如果在关闭创建资源的过程中也可能会抛异常怎么办？java1.7之前，只能在finally子句里再写try-catch子句，这么做不仅会使跟业务逻辑关联不大的finally子句的代码过于庞大，更严重的是一旦在finally里抛出异常（通常是关闭链接时抛出的异常，跟业务没关系），try里跟业务resource相关的异常就不会被抛出了，而这部分异常才是我们真正关心的，因此java1.7之后支持try-with-resource这种更加优雅的写法。
使用try-with-resource语法的前提是这个resource类实现了AutoCloseable接口，并实现了唯一的方法close()，则在try-catch里打开了这个resource后，无需在finally子句里调用resource.close()方法，若调用 resource.close()抛出异常，则抛出的这个异常会被抑制，在打印的异常信息中会由 Suppressed关键字开头注明，addSusppressed 方法将resource.close()抛出的异常添加到原来的异常中，如果想要获取被抑制的异常列表，可以调用 getSuppressed 方法来获取。

自己写了个Demo如下：

public class MyResource implements AutoCloseable {
    private int number;
    public MyResource(int number)
    {
        this.number = number;
    }
    public int getNumber() throws MyException
    {
        if (this.number == 60)
        {
            throw new MyException("number是60，要抛出MyException异常");
        }
        return this.number;
    }
    @Override
    public void close() throws Exception {
        System.out.println("成功关闭resource");
    }
}

Main如下：

public class Main {
    public static void main(String[] args) {
        int number = 60;
        try {
            MyResource myResource = new MyResource(number);
            System.out.println("resource的number是：" + myResource.getNumber());
        }
        catch (MyException e)
        {
            e.printStackTrace();
        }
    }
}

打印结果下：

Exception.MyException: number是60，要抛出MyException异常
    at Exception.MyResource.getNumber(MyResource.java:23)
    at Exception.Main.main(Main.java:19)

打印结果里为什么没有调用close方法打印相关信息？？？为什么？？？
更加详细的例子可以参考链接3。

复现一下finally块里抛出异常会覆盖try-catch的异常：

public class Main {
    public static void main(String[] args) {
        try {
            // 异常发生
            System.out.println(2 / 0);
        } catch (Exception e) {
            System.out.println("catch exception");
            throw new RuntimeException("2 / 0");
        } finally {
            System.out.println("finally exception");
            throw new RuntimeException("覆盖try-catch的异常");
        }
    }
}

结果：只会打印finally块里的语句，catch块里的语句没打印，且try里的2 / 0的异常没有抛出，说明finally块里抛出异常，会抑制掉try-catch中的异常。

3、开发过程中涉及异常的注意点

这里把阿里巴巴异常规范罗列出来，其中标红色的是我在实际开发中遇到过的，尤为重要。

【强制】 Java 类库中定义的可以通过预检查方式规避的 RuntimeException 异常不应该通过
catch 的方式来处理，比如： NullPointerException， IndexOutOfBoundsException 等等。
说明：无法通过预检查的异常除外，比如，在解析字符串形式的数字时，不得不通过 catch
NumberFormatException 来实现。
正例： if (obj != null) {…}
反例： try { obj.method(); } catch (NullPointerException e) {…}
【强制】异常不要用来做流程控制，条件控制。
说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式
要低很多。
【强制】 catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。
对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
说明：对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利
于定位问题，这是一种不负责任的表现。
正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于
简单，在程序上作出分门别类的判断，并提示给用户。
【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请
将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的
内容。
【强制】有 try 块放到了事务代码中， catch 异常后，如果需要回滚事务，一定要注意手动回
滚事务。
【强制】 finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。
说明：如果 JDK7 及以上，可以使用 try-with-resources 方式。
【强制】不要在 finally 块中使用 return。
说明： finally 块中的 return 返回后方法结束执行，不会再执行 try 块中的 return 语句。
【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。
说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。
【推荐】方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分
说明什么情况下会返回 null 值。
说明：本手册明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回
null 的情况。
【推荐】防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：
1）返回类型为基本数据类型， return 包装数据类型的对象时，自动拆箱有可能产生 NPE。
反例： public int f() { return Integer 对象}，如果为 null，自动解箱抛 NPE。
2）数据库的查询结果可能为 null。
3）集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。
4）远程调用返回对象时，一律要求进行空指针判断，防止 NPE。
5）对于 Session 中获取的数据，建议 NPE 检查，避免空指针。
6）级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。
正例：使用 JDK8 的 Optional 类来防止 NPE 问题。
【推荐】定义时区分 unchecked / checked 异常，避免直接抛出 new RuntimeException()，
更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义
过的自定义异常，如： DAOException / ServiceException 等。
【参考】对于公司外的 http/api 开放接口必须使用“错误码”；而应用内部推荐异常抛出；
跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess()方法、 “错误码”、 “错误简
短信息”。
说明：关于 RPC 方法返回方式使用 Result 方式的理由：
1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。
2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用
端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输
的性能损耗也是问题。
【参考】避免出现重复的代码（Don’t Repeat Yourself），即 DRY 原则。
说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副
本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。
正例：一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：
private boolean checkParam(DTO dto) {…}
参考
慕课网：一文读懂 JAVA 异常处理 zhuanlan.zhihu.com
里奥ii：Java异常简介、异常捕获还是上抛总结 zhuanlan.zhihu.com
使用try-with-resources优雅关闭资源 - 掘金 juejin.im

Java异常概述

1、Java异常类型结构

2、Java异常处理措施

2.1 自定义异常

2.2 异常的抛出 throws/throw

2.3 捕获异常 try-catch-finally

2.4 try-with-resource

3、开发过程中涉及异常的注意点

参考