java 异常类

异常类体系

在Java语言以前，代表各种异常情况一般使用数字，例如常见的浏览器中的404错误，以及Windows中的错误编号等，使用这些数字可以代表各种异常情况，但是最大的不足在于这些数字不够直观，无法很直接的从这些数字中知道异常出现的原因。

所以在Java语言中代表异常时，不再使用数字来代表各种异常的情况，而是使用一个专门的类来代表一种特定的异常情况，在系统中传递的异常情况就是该类的对象，所有代表异常的类组成的体系就是Java语言中的异常类体系。

为了方便对于这些可传递对象的管理，Java API中专门设计了java.lang.Throwable类，只有该类子类的对象才可以在系统的异常传递体系中进行。该类的两个子类分别是：

1、Error类

该类代表错误，指程序无法恢复的异常情况。对于所有错误类型以及其子类，都不要求程序进行处理。常见的Error类例如内存溢出StackOverflowError等。

2、Exception类

该类代表异常，指程序有可能恢复的异常情况。该类就是整个Java语言异常类体系中的父类。使用该类，可以代表所有异常的情况。

在Java API中，声明了几百个Exception的子类分别来代表各种各样的常见异常情况，这些类根据需要代表的情况位于不同的包中，这些类的类名均以 Exception作为类名的后缀。如果遇到的异常情况，Java API中没有对应的异常类进行代表，也可以声明新的异常类来代表特定的情况。

在这些异常类中，根据是否是程序自身导致的异常，将所有的异常类分为两种：

1、RuntimeException及其所有子类

该类异常属于程序运行时异常，也就是由于程序自身的问题导致产生的异常，例如数组下标越界异常ArrayIndexOutOfBoundsException等。

该类异常在语法上不强制程序员必须处理，即使不处理这样的异常也不会出现语法错误。

2、其它Exception子类

该类异常属于程序外部的问题引起的异常，也就是由于程序运行时某些外部问题导致产生的异常，例如文件不存在异常FileNotFoundException等。

该类异常在语法上强制程序员必须进行处理，如果不进行处理则会出现语法错误。

熟悉异常类的分类，将有助于后续语法中的处理，也使得在使用异常类时可以选择恰当的异常类类型。

由于异常类的数量非常多，在实际使用时需要经常查阅异常类的文档，下面列举一些常见的异常类，如下表所示：

常见异常类





runtime exception和checked exception 的不同
Java提供了两类主要的异常：runtime exception和checked exception。所有的checked exception是从java.lang.Exception类衍生出来的，而runtime exception则是从java.lang.RuntimeException或java.lang.Error类衍生出来的。

它们的不同之处表现在两方面：机制上和逻辑上。

　　一、机制上

　　它们在机制上的不同表现在两点：1.如何定义方法；2. 如何处理抛出的异常。请看下面CheckedException的定义：

public class CheckedException extends Exception
{
　public CheckedException() {}
　public CheckedException( String message )
　{
　　super( message );
　}
} 

以及一个使用exception的例子：

public class ExceptionalClass
{
　public void method1()
　　throws CheckedException
　　{
　　　// ... throw new CheckedException( "...出错了" );
　　}
　public void method2( String arg )
　　{
　　　if( arg == null )
　　　{
　　　　throw new NullPointerException( "method2的参数arg是null!" );
　　　}
　　}
　public void method3() throws CheckedException
　　{
　　　method1();
　　}
} 

你可能已经注意到了，两个方法method1()和method2()都会抛出exception，可是只有method1()做了声明。另外，method3()本身并不会抛出exception，可是它却声明会抛出CheckedException。在向你解释之前，让我们先来看看这个类的main()方法：

public static void main( String[] args )
{
　ExceptionalClass example = new ExceptionalClass();
　try
　{
　　example.method1();
　　example.method3();
　}
　catch( CheckedException ex ) { } example.method2( null );
} 

在main()方法中，如果要调用method1()，你必须把这个调用放在try/catch程序块当中，因为它会抛出Checked exception。

　　相比之下，当你调用method2()时，则不需要把它放在try/catch程序块当中，因为它会抛出的exception不是checked exception，而是runtime exception。会抛出runtime exception的方法在定义时不必声明它会抛出exception。

　　现在，让我们再来看看method3()。它调用了 method1()却没有把这个调用放在try/catch程序块当中。它是通过声明它会抛出method1()会抛出的exception来避免这样做的。它没有捕获这个exception，而是把它传递下去。实际上main()方法也可以这样做，通过声明它会抛出Checked exception来避免使用try/catch程序块（当然我们反对这种做法）。

　　小结一下：

　　* Runtime exceptions：

　　　在定义方法时不需要声明会抛出runtime exception；

　　　在调用这个方法时不需要捕获这个runtime exception；

　　　runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。

　　* Checked exceptions：

　　　定义方法时必须声明所有可能会抛出的checked exception；

　　　在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去；

　　　checked exception是从java.lang.Exception类衍生出来的。

二、逻辑上

　　从逻辑的角度来说，checked exceptions和runtime exception是有不同的使用目的的。checked exception用来指示一种调用方能够直接处理的异常情况。而runtime exception则用来指示一种调用方本身无法处理或恢复的程序错误。

　　checked exception迫使你捕获它并处理这种异常情况。以java.net.URL 类的构建器(constructor)为例，它的每一个构建器都会抛出MalformedURLException。 MalformedURLException就是一种checked exception。设想一下，你有一个简单的程序，用来提示用户输入一个URL，然后通过这个URL去下载一个网页。如果用户输入的URL有错误，构建器就会抛出一个exception。既然这个exception是checked exception，你的程序就可以捕获它并正确处理：比如说提示用户重新输入。

　　再看下面这个例子：

public void method()
{
　int [] numbers = { 1, 2, 3 };
　int sum = numbers[0] + numbers[3];
}

在运行方法method()时会遇到ArrayIndexOutOfBoundsException（因为数组numbers的成员是从0到2）。对于这个异常，调用方无法处理/纠正。这个方法method()和上面的method2()一样，都是runtime exception的情形。上面我已经提到，runtime exception用来指示一种调用方本身无法处理/恢复的程序错误。而程序错误通常是无法在运行过程中处理的，必须改正程序代码。

　　总而言之，在程序的运行过程中一个checked exception被抛出的时候，只有能够适当处理这个异常的调用方才应该用try/catch来捕获它。而对于runtime exception，则不应当在程序中捕获它。如果你要捕获它的话，你就会冒这样一个风险：程序代码的错误(bug)被掩盖在运行当中无法被察觉。因为在程序测试过程中，系统打印出来的调用堆栈路径(StackTrace)往往使你更快找到并修改代码中的错误。有些程序员建议捕获runtime exception并纪录在log中，我反对这样做。这样做的坏处是你必须通过浏览log来找出问题，而用来测试程序的测试系统（比如Unit Test）却无法直接捕获问题并报告出来。

　　

评论

1 楼 javawen 2010-07-27  

dadsdddddd