区分运行时异常和编译时异常

jianchen 写道

当你确信方法的使用者会处理你的方法抛出的异常时，可以使用编译时异常。不处理编译时异常，程序编译不能通过。

而运行时异常给了方法的调用者以选择，他可以选择处理，也可以不处理。处理的话，进行catch即可，不处理的话就什么也不做就是了。不处理运行时异常，程序编译能够通过。

 在网上搜到一篇现成的文章，链接如下：

原文：http://blog.csdn.net/xkqtest/archive/2008/04/10/2275676.aspx

 

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异常 了。