异常类

1.异常的定义

    一个系统中定义异常应遵循如下几个原则：

a. 系统中如果某个模块功能比较单一，建议将所有异常放在一个package内；如果某个模块有很多子模块，建议将异常放各个对应子模块内；

b. 异常名称必须是自定义的；

c. 自定义异常都继承之Exception(不要继承RuntimeException)；

d. 所有异常含有含有两个构造器:一个缺省构造器，一个用于构建异常链的构造器。

示例如下：

public class MyException1 extends Exception{
public MyException1() {
 
}

public MyException1(Throwable cause) {
  super(cause);
}
}

2.异常的处理

   在异常处理程序中遵循如下原则：

a. 本方法能处理的异常，异常处理程序中就处理掉，不向外层传递;

b. 本方法不能处理的异常，必须使用异常链，封装为本模块的异常向上传递。

示例如下：

public class test {
public static void f() throws MyException1{
  throw new MyException1();
}

public static void main(String[] args) throws MyException2{
  try {
   f();
  } catch(MyException1 e) {
   throw new MyException2(e);
  }
}
}

【注】：Bruce   Eckel指出建议使用runtimeException封装异常。本人认为，在系统设计中不应该这么做，因为在开发实际系统是，各个模块开发人员不一样，如果开发人员用runtimeException封装了异常，其他使用该模块的开发人员很难知道模块中抛出了异常




   在java的异常类体系中,Error和RuntimeException是非检查型异常，其他的都是检查型异常。
   java语法中所有方法都可以在不声明throws的情况下抛出RuntimeException及其子类 ，但不可以在不声明的情况下抛出非RuntimeException，简单的说，非RuntimeException要自己写catch块处理掉。
 
   比如
   假设自己定义了个非RuntimeException： MyException
   public String getFirstTwo(String src){
      //if(src == null) throw new MyException( "String is null "); 
      return src.substring(0, 2);
   }
   注释的语句不放开，不会出错
    如果别的地方调用了getFirstTwo(null),在getFirstTwo方法中，null.substring(0,2)方法是会抛出运行时异常NullPointerException的，虽然getFirstTwo方法并没有申明会throws NullPointerException,但是实际运行中这个异常还是会从getFirstTwo方法抛出给调用这个方法的地方。
    而如果把注释语句放开，则无法通过编译，MyException是一个非运行时异常，如果方法中的语句可能抛出这个异常必须将方法声明为public String getFirstTwo(String src) throws MyException才可以理解！！！

     常见的RuntimeException:
    ClassCastException
    NullPointerException
    ArrayIndexOutOfBoundsException
    IllegalArgumentException
    NumberFormatException

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

    下面内容来自网上：

   但最近我在项目却遇的问题，恰恰是这因为没有对运行时异常进行处理，而导致程序在运行一小段时间后就当了。事情是这样的，由于写程序时我对多线程的并发处理不太会，也就把一个模块写成了单线程的，由它来循环处理一个数据队列。但没想到队列里面的数据有一些与预期的格式不一样，处理这样的数据时，程序就抛出了运行时异常。由于没有对异常进行处理，这个异常也就抛到了Thread.run()。最后这个处理线程肯定是被终止了，队列里面的数据也就不会再有程序去处理了。
   这个结果显然不是我想要的，队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而，影响下面对正常数据的处理啊。
   所以最后我在程序的循环处理模块，里面加了一个catch处理，来扑捉所有的异常，决不让这个处理线程退出，要知道我的所有数据还要依靠他来处理。在这个场景这样处理可能是一个比较好的应用，但并不代表在所有的场景你都应该如此。如果在其它场景，遇到了一些错误，如果退出程序比较好，这时你就可以不太理会运行时异常，或者是通过对异常的处理显式的控制程序退出。
   知道了虚拟机怎么处理运行时异常，也更进一步理解了Sping对Hibernate的封装了。由于Hibernate是和数据库打交道，所以总是要抛出一些乱七八糟的checked异常，平时我们根本不想catch这些异常。因为这些异常总是把代码弄的乱乱的，搞的到处都是try{} catch(){}块，并且常常加了catch块，也并不能把程序从异常中恢复过来（异常处理的目标之一就是为了把程序从异常中恢复出来）。为了通过编译器的检查，程序员被迫加上了catch块，往往这些catch并没有发挥他应有的作用，反而带来了很大的不便。所以Spring对Hibernate封装时就把Hibernate的异常进行了封装，全部封装成RuntimeException了。也就是说由Spring来扑捉Hibernate抛出的异常，然后Spring把异常转换成Spring自己定义的运行时异常再抛出。这样我们在编码时使用Spring来调用Hibernate时，可以不用catch块来处理一些不必要的异常。当然你确实要是想处理，也可以通过添加cathc块去处理异常。不过这个时候，你的Catch就要扑捉RuntimeException了，而不是一般的checked异常了。