java异常处理设计

如果一个方法throws一个非运行时异常，调用该方法，编译器会要求你强制捕获异常。

运行时异常，编译器不强制程序员一定要捕获异常。可以这么记忆：编译器在编译期间无法确定，所以编译器无法给予强制提示。

总结：非运行时异常，编译器都会要求强制捕获异常，或者向上抛出异常。

 

Throwable 是所有 Java 程序中错误处理的父类 ，有两种子类： Error 和 Exception 。

Error ：表示由 JVM 所侦测到的无法预期的错误，由于这是属于 JVM 层次的严重错误 ，导致 JVM 无法继续执行，因此，这是不可捕捉到的，无法采取任何恢复的操作，顶多只能显示错误信息。

Exception ：表示可恢复的例外，这是可捕捉到的。

 

Exception包括非运行时异常和运行时异常。

在Exception中有一个子类RuntimeException，该类及其子类不需要强制捕获。

 

非运行时异常，也就是我们经常遇到的 IO 异常，以及 SQL 异常都是这种异常。 对于这种异常， JAVA 编译器强制要求我们必需对出现的这些异常进行 catch 。

面对这种异常不管我们是否愿意，只能自己去写一大堆 catch 块去处理可能的异常。

 

运行时异常，我们可以不处理。当出现这样的异常时，总是由虚拟机接管。比如：我们从来没有人去处理过 NullPointerException 异常，它就是运行时异常，并且这种异常还是最常见的异常之一。

出现运行时异常后，系统会把异常一直往上层抛，一直遇到处理代码。如果没有处理块，到最上层，如果是多线程就由 Thread.run() 抛出 ，如果是单线程就被 main() 抛出 。

抛出之后，如果是线程，这个线程也就退出了。如果是主程序抛出的异常，那么这整个程序也就退出了。

运行时异常是 Exception 的子类，也有一般异常的特点，是可以被 Catch 块处理的。只不过往往我们不对他处理罢了。

也就是说，你如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。

如果不想终止，则必须扑捉所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处理。 

在这个场景这样处理可能是一个比较好的应用，但并不代表在所有的场景你都应该如此。

如果在其它场景，遇到了一些错误，如果退出程序比较好，这时你就可以不太理会运行时异常 ，或者是通过对异常的处理显式的控制程序退出。

异常处理的目标之一就是为了把程序从异常中恢复出来 。

 

更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译。