"运行时异常"也要扑捉(JAVA版）(原创）

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

 

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

 

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

 

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

 

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

 

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

 

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

    

   上面的观点，仅仅是一点经验参考，完全是一家之言 ，如果有写错的地方请指教(email: flyfoxs+blog0528@gmail.com)。runtime exception和checked exception这两种异常可能并不太好理解，如果不太理解的话 ，可以参考下面的文献。

 

 

参考文献： http://www.pconline.com.cn/pcjob/process/sun/experience/0511/719750.html