java运行时异常

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

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

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

Java提供了两类主要的异常:runtime exception和checked exception。

Java提供了两类主要的异常:runtime exception和checked exception。checked 异常也就是我们经常遇到的IO异常，以及SQL异常都是这种异常。对于这种异常，JAVA编译器强制要求我们必需对出现的这些异常进行catch。所以，面对这种异常不管我们是否愿意，只能自己去写一大堆catch块去处理可能的异常。

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

    以前一直没仔细想过出现运行时异常了系统会怎样工作，最近在一个模块排错时，才无意中发现了系统是如何处理运行时异常。出现运行时异常后，系统会把异常一直往上层抛，一直遇到处理代码。如果没有处理块，到最上层，如果是多线程就由Thread.run()抛出，如果是单线程就被main()抛出。抛出之后，如果是线程，这个线程也就退出了。如果是主程序抛出的异常，那么这整个程序也就退出了。运行时异常是Exception的子类，也有一般异常的特点，是可以被Catch块处理的。只不过往往我们不对他处理罢了。

    也就是说，你如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。如果程序的退出刚好是你期望的结果，那就万事OK了。

   但最近我在项目却遇的问题，恰恰是这因为没有对运行时异常进行处理，而导致程序在运行一小段时间后就当了。事情是这样的，由于写程序时我对多线程的并发处理不太会，也就把一个模块写成了单线程的，由它来循环处理一个数据队列。但没想到队列里面的数据有一些与预期的格式不一样，处理这样的数据时，程序就抛出了运行时异常。由于没有对异常进行处理，这个异常也就抛到了Thread.run()。最后这个处理线程肯定是被终止了，队列里面的数据也就不会再有程序去处理了。这个结果显然不是我想要的，队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而，影响下面对正常数据的处理啊。

    所以最后我在程序的循环处理模块，里面加了一个catch处理，来扑捉所有的异常，决不让这个处理线程退出，要知道我的所有数据还要依靠他来处理呢 （^_^ )。在这个场景这样处理可能是一个比较好的应用，但并不代表在所有的场景你都应该如此。如果在其它场景，遇到了一些错误，如果退出程序比较好，这时你就可以不太理会运行时异常，或者是通过对异常的处理显式的控制程序退出。

   知道了虚拟机怎么处理运行时异常，也更进一步理解了Sping对Hibernate的封装了。由于Hibernate是和数据库打交道，所以总是要抛出一些乱七八糟的checked异常，平时我们根本不想catch这些异常。因为这些异常总是把代码弄的乱乱的，搞的到处都是try{} catch(){}块，并且常常加了catch块，也并不能把程序从异常中恢复过来（异常处理的目标之一就是为了把程序从异常中恢复出来）。为了通过编译器的检查，程序员被迫加上了catch块，往往这些catch并没有发挥他应有的作用，反而带来了很大的不便。所以Spring对Hibernate封装时就把Hibernate的异常进行了封装，全部封装成运行时异常了。也就是Spring来扑捉Hibernate抛出的异常，然后Spring把异常转换成Spring自己定义的运行时异常再抛出。这样我们在编码时使用Spring来调用Hibernate时，可以不用catch块来处理一些不必要的异常。当然你确实要是想处理，也可以通过添加cathc块去处理异常。不过这个时候，你的Catch就要扑捉运行时异常了，而不是一般的checked异常了。