异常的分类
这是最直接的异常分类图，从图中可以看见，顶层类是Throwable,子类中分为Error和Exception。
但是java中对这些分类还做了另外一种划分。分为checked和unchecked异常。
- unchecked异常：Error和RuntimeException及其子类
- checked异常：Exception中子类除了RuntimeException，其余都是checked异常
受检异常和非受检异常的区别
受检异常：java编译器要求程序必须捕获或者声明抛出异常。
非受检异常：默认情况下会得到自动处理，所以不用通常捕获。
- 问题1：这两种异常再什么场景使用？
- 问题2：在哪里处理异常？
- 问题3：如何处理这些异常？
问题1：这两种异常在什么场景使用？
有关于场景的问题，必然是与业务相关。关注是否是核心功能点。
问题2：在哪里处理异常？
在哪里处理异常，与上下文相关。不同的场景，相同的业务，对异常的处理也不相同。
例子：同样是一个login方法,在LoginService中，和在BindService
- Login在LoginService中是核心功能点，在BindService中是普通功能点。所以处理异常的方式是有所区别的。
- 接下来思考，login这个方法的异常应该是什么类型的异常？
checked,unchecked?- 显然是unchecked异常，这个异常是要去处理的异常，（unchecked异常，是代码的错误，需要在该方法中直接去修改），但是有些系统定义的checked异常，如何处理，看问题3。
- 那么对这个异常到底是try…catch直接处理掉， 还是 throw向上抛出？
- 这是不能直接处理的，因为在不同的场景中重要性不同，所以不能笼统的处理，必须返回到service业务层进行处理。所以用throw向上抛出。【如果就在本层处理掉，那么所有的业务调用该方法，都执行了同样的处理，这显然是不合理的。】
问题3：如何处理异常？
同样是与业务相关
- 如果是核心功能点，那么显然是要返回给用户展示的，提示用户重新进行操作，所以在try…catch checked异常之后要抛出一个unchecked异常，也就是RuntimeException。当然，如果方法中抛出的就已经是runtimeException，那么就让其自动向上处理。
- 如果是非核心功能点，那么就自动处理掉,一般是做打印日志处理。（试想，如果service中的记录日志方法异常，总不可能返回给用户处理吧，只需要自己处理掉就行了。）
在有拦截器的情况下
自定义异常一般使用runtimeException，因为runtimeException是自动向上抛出的。可以统一在拦截器处进行集中处理（比如日志处理。），这样做到了解耦，增强了健壮性。