1. 从根上说起
Java异常体系的根即所有异常的基类：Throwable，一个很像接口的基类，不过它确实是个类，包含了异常处理的一些基本操作。顾名思义，Throwable即可抛出的。Java异常的可抛出特性决定了对程序中异常情况的处理方式，通过抛出来声明这里出现了一个非正常流程的东西，留给你来处理。
2. Error和Exception
Throwable的下一级（直接子类）分为Error和Exception。从名称来看也能区分两者：错误和异常。
Error即错误，通常为程序运行中不可预见的，出现概率也很小的异常情况。这种异常出现一般都会导致程序处于不正常的状态或者不可恢复。这个最常见的莫过于OutOfMemoryError了（OOM），因为程序运行所需的内存空间不足导致内存溢出。这种错误的出现程序本身是无法预知的，而且出现后程序已经不能正常运行（虽然进程没有结束退出）。这一类错误在开发时无需考虑。
Exception即异常，跟Error正好处于截然不同的领域，它通常为可预见的意外情况，而且不会危及到程序自身的运行。开发过程中需要关注和处理的即这一类异常，需要考虑进行捕获、处理或者传递。
3. checked和unchecked
Exception的下一级实现分为两类：受检异常-checked和非受检异常unchecked。所谓受检和非受检即是说开发中遇到异常时是否 必需 显示的去捕获处理。相较于这个名字，也许你会更喜欢另一种叫法：运行期异常（RuntimeException）和非运行期异常。
RuntimeException及它的所有子类都称为运行期异常，其他所有不是继承RuntimeException的即非运行期异常，
RuntimeException
最常见的运行期异常莫过于空指针异常NullPointerException，还有数组越界异常IndexOutOfBoundsException。这类异常在“运行期”才知道是否有可能抛出（运行时才知道是否对象为空或者操作的索引超出界限），所以不要求强制去捕获（对应unchecked异常）。
普通异常
其他普通异常则是在开发时即知道（调用方法签名进行了声明）可能会抛出的异常。比如常见的IOException及它的子类。声明了这类异常的方法通常是意识到程序有可能出现问题，所以作出一个声明并要求你去处理，你必需明确的对它进行捕获try-catch或者传递throws。虽然现在一直有种争论认为这完全是一种错误的设计，因为大多数情况下出现的异常我们都是无法处理了，并且对异常的捕获处理不仅使程序效率降低而且干扰了代码的可读性。
个人的理解是，应该尽量少定义这种普通的异常，除非：你有需要调用者不得不去处理的理由而不是简单的捕获后转化再抛出。
4. 异常的使用处理
在了解了异常的设计机制后，再来了解下如何对异常进行处理。通常我们需要处理的仅仅是非运行期异常。通过使用Java提供的try-catch-finally对可能抛出异常的代码进行捕获处理，或者使用针对资源的try-with-resources来简化代码。以下为异常处理的一些建议：
- 就近处理
在调用可能抛出异常的代码时，应该尽可能的就近捕获处理，而不是传递抛出。首先：如果直接传递抛出，当设计到底层异常修改时，需要修改调用链上的一连串声明和处理；其次：通常直接调用方会更明了异常出现时应该做怎样的处理，即使是简单的转换为自定义的运行期异常再抛出。 - 封装处理
对于可能会抛出异常的代码，应该进行独立的封装把它变为一个不会抛出异常的调用。首先：封装后上层的业务代码没有了try-catch更清晰易读，同时避免try-catch大段的代码。其次：即时底层异常发生变化也可以在封装层进行修改处理。 - 不要生吞异常
这个已经是大家都明了的一个原则了。对异常捕获后不应该不做任何的处理，仅为了捕获异常而捕获。这样做为程序出问题后的排查诊断买下隐患。 - 不要直接打印异常堆栈
通常在实际的开发项目中都会继承日志系统，使用日志输出，不要直接调用printStackTrace()。因为常见的日志机制都提供了输出时同时输出异常堆栈，如果直接调用会造成重复输出；另外直接调用的输出为标准错误输出-通常为控制台，应当输出到错误日志文件。 - 不要直接捕获Throwable或者Exception
代码中应该捕获特定的异常并分别进行处理。捕获Throwable会同时捕获Error类的异常，可能会造成程序无法正常运行。捕获Exception个人认为只能出现在对外的接口，并且调用方无法很好处理异常的情况。 - 优先使用系统定义异常
Java中已经定义了很多常见的异常类型：IllegalArgumentException-非法参数异常，UnsupportedOperationException-不支持的操作异常。 - 优先使用自定义运行期异常替代错误码
除非提供的为对外开放的API接口，否则建议使用自定义的异常来替代各种错误码。这样调用方的处理更流畅自然。