异常指的是程序运行时出现的不正常情况。程序运行过程中难免会发生异常,发生异常并不可怕,程序员应该考虑到有可能发生这些异常,编程时应能正确的处理异常,使成为健壮的程序。
异常是相对于 return 的一种退出机制,可以由系统触发,也可以由程序通过 throw 语句触发,异常可以通过 try/catch 语句进行捕获并处理,如果没有捕获,则会导致程序退出并输出异常栈信息。
Java 的异常类是处理运行时的特殊类,每一种异常对应一种特定的运行错误.所有Java异常类都是系统类库中 Exception 类的子类。

异常类继承层次图
所有的异常类都直接或间接地继承于 java.lang.Throwable 类,在Throwable 类有几个非常重要的方法:
Throwable 有两个直接子类:Error 和 Exception。
Java 的异常处理机制会区分两种不同的异常类型:已检异常 checked 和未检异常 unchecked (运行时异常)。
在明确的特定情况下抛出,经常是应用能部分或完全恢复的情况。例如,某段代码要在多个可能的目录中寻找配置文件。如果试图打开的文件不在某个目录中,就会抛出 FileNotFoundException 异常。在这个例子中,我们想捕获这个异常,然后在文件可能出现的下一个位置继续尝试。也就是说,虽然文件不存在是异常状况,但可以从中恢复,这是意料之中的失败。
在 Java 环境中有些失败是无法预料的,这些失败可能是由运行时条件或滥用库代码导致的。例如把无效的 null 传给使用对象或数组的方法,会抛出 NullPointerException 异常。基本上任何方法在任何时候都可能抛出未检异常。这是 Java 环境中的墨菲定律:“会出错的事总会出错。”从未检异常中恢复,虽说不是不可能,但往往很难,因为完全不可预知。运行时异常往往是程序员所犯错误导致的,健壮的程序不应该发生运行时异常。
若想区分已检异常和未检异常,记住两点:异常是 Throwable 对象,而且异常主要分为两类,通过 Error 和 Exception 子类标识。只要异常对象是 Error 类,就是未检异常。Exception 类还有一个子类 RuntimeException , RuntimeException 类的所有子类都属于未检异常。除此之外,都是已检异常。
提示:对于运行时异常通常不采用抛出或捕获处理方式,而是应该提前预判,防止这种发生异常,做到未雨绸缪。例如在进行除法运算之前应该判断除数是非零的,修改代码进行提前预判这样处理要比通过 try-catch 捕获异常要友好的多。
通过以上介绍可以看出,未受检异常和受检异常的区别如下:受检异常必须出现在 throws 语句中,调用者必须处理,Java 编译器会强制这一点,而未受检异常则没有这个要求。
为什么要有这个区分呢?我们自己定义异常的时候应该使用受检还是未受检异常呢?对于这个问题,业界有各种各样的观点和争论,没有特别一致的结论。
一种普遍的说法是:未受检异常表示编程的逻辑错误,编程时应该检查以避免这些错误,比如空指针异常,如果真的出现了这些异常,程序退出也是正常的,程序员应该检查程序代码的 bug 而不是想办法处理这种异常。受检异常表示程序本身没问题,但由于 I/O、网络、数据库等其他不可预测的错误导致的异常,调用者应该进行适当处理。
但其实编程错误也是应该进行处理的,尤其是 Java 被广泛应用于服务器程序中,不能因为一个逻辑错误就使程序退出。所以,目前一种更被认同的观点是:Java 中对受检异常和未受检异常的区分是没有太大意义的,可以统一使用未受检异常来代替。
这种观点的基本理由是:无论是受检异常还是未受检异常,无论是否出现在 throws 声明中,都应该在合适的地方以适当的方式进行处理,而不只是为了满足编译器的要求盲目处理异常,既然都要进行处理异常,受检异常的强制声明和处理就显得烦琐,尤其是在调用层次比较深的情况下。
其实观点本身并不太重要,更重要的是一致性,一个项目中,应该对如何使用异常达成一致,并按照约定使用。
Exception 类有若干子类,每个子类代表一种特定的运行错误,这些子类有的是系统事先定义好并包含在Java类库中的,成为系统定义的运行异常。
try catch finally throw throws。try {语句块;}
catch (异常类名 参变量名) {语句块;}
finally
{语句块;} //定义一定执行的代码:通常用于关闭资源try-catch 不仅可以嵌套在 try 代码块中,还可以嵌套在 catch 代码块或 finally 代码块,finally 代码块后面会详细介绍。try-catch 嵌套会使程序流程变的复杂,如果能用多catch捕获的异常,尽量不要使用 trycatch 嵌套。特别对于初学者不要简单地使用 Eclipse 的语法提示不加区分地添加 try-catch 嵌套,要梳理好程序的流程再考虑 try-catch 嵌套的必要性。
Java 7 推出了多重捕获(multi-catch)技术, 可以把这些异常合并处理
try {
// 可能会发生异常的语句
} catch (IOException | ParseException e) {
// 调用方法methodA处理
}finally 语句有一个执行细节,如果在 try 或者 catch 语句内有 return 语句,则 return 语句在 finally 语句执行结束后才执行,但 finally 并不能改变返回值,我们来看下面的代码。
public static int yyy() {
int ret = 1;
try {
return ret;
} finally {
ret = 2;
}
}输出结果为 1。
如果在finally中也有return语句呢?try 和 catch 内的 return 会丢失,实际会返回finally中的返回值。
一般而言,为避免混淆,应该避免在 finally 中使用 return 语句或者抛出异常,如果调用的其他代码可能抛出异常,则应该捕获异常并进行处理。
有时在 try-catch 语句中会占用一些非 Java 资源,如:打开文件、网络连接、打开数据库连接和使用数据结果集等,这些资源并非 Java 资源,不能通过 JVM 的垃圾收集器回收,需要程序员释放。为了确保这些资源能够被释放可以使用 finally 代码块或 Java 7 之后提供自动资源管理(Automatic Resource Management)技术。
try-catch 语句后面还可以跟有一个 finally 代码块,try-catch-finally 语句语法如下:
注意:为了代码简洁等目的,可能有的人会将 finally 代码中的多个嵌套的try-catch语句合并。每一个close()方法对应关闭一个资源,如果某一个 close() 方法关闭时发生了异常,那么后面的也不会关闭,因此这种代码是有缺陷的。
使用 finally 代码块释放资源会导致程序代码大量增加,一个 finally 代码块往往比正常执行的程序还要多。在Java 7之后提供自动资源管理(Automatic Resource Management)技术,可以替代 finally 代码块,优化代码结构,提高程序可读性。
自动资源管理是在try语句上的扩展,语法如下:
try (声明或初始化资源语句) {
//可能会生成异常语句
} catch(Throwable e1){
//处理异常e1
} catch(Throwable e2){
//处理异常e1
} catch(Throwable eN){
//处理异常eN
}在 try 语句后面添加一对小括号“()”,其中是声明或初始化资源语句,可以有多条语句语句之间用分号“;”分隔。
示例代码如下:
public class HelloWorld {
public static void main(String[] args) {
Date date = readDate();
System.out.println("读取的日期 = " + date);
}
public static Date readDate() {
// 自动资源管理
try (FileInputStream readfile = new FileInputStream("readme.txt");
InputStreamReader ir = new InputStreamReader(readfile);
BufferedReader in = new BufferedReader(ir)) {
// 读取文件中的一行数据
String str = in.readLine();
if (str == null) return null;
DateFormat df = new SimpleDateFormat("yyyy-MM-dd");
Date date = df.parse(str);
return date;
} catch (IOException e) {
System.out.println("处理IOException...");
e.printStackTrace();
} catch (ParseException e) {
System.out.println("处理ParseException...");
e.printStackTrace();
}
return null;
}
}注意 所有可以自动管理的资源需要实现 AutoCloseable 接口,上述代码中三个输入流 FileInputStream、InputStreamReader 和 BufferedReader 从 Java 7之后实现 AutoCloseable 接口,具体哪些资源实现 AutoCloseable 接口需要查询 API文档。
资源的声明和初始化放在 try 语句内,不用再调用 finally,在语句执行完try语句后,会自动调用资源的 close() 方法。资源可以定义多个,以分号分隔。在 Java 9 之前,资源必须声明和初始化在 try 语句块内,Java 9去除了这个限制,资源可以在try语句外被声明和初始化,但必须是 final 的或者是事实上 final 的(即虽然没有声明为final但也没有被重新赋值)。
在一个方法中如果能够处理异常,则需要捕获并处理。但是本方法没有能力处理该异常,捕获它没有任何意义,则需要在方法后面声明抛出该异常,通知上层调用者该方法有可以发生异常。
注意:如果声明抛出的多个异常类之间有父子关系,可以只声明抛出父类。但如果没有父子关系情况下,最好明确声明抛出每一个异常,因为上层调用者会根据这些异常信息进行相应的处理。假如一个方法中有可能抛出 IOException 和 ParseException 两个异常,那么声明抛出 IOException 和 ParseException 呢?还是只声明抛出 Exception 呢?因为 Exception 是 IOException 和 ParseException 的父类,只声明抛出 Exception 从语法是允许的,但是声明抛出 IOException 和ParseException 更好一些。
有些公司为了提高代码的可重用性,自己开发了一些 Java 类库或框架,其中少不了自己编写了一些异常类。实现自定义异常类需要继承 Exception 类或其子类,如果自定义运行时异常类需继承RuntimeException 类或其子类。
我们通过继承 Exception 或者 RuntimeException 来定义一个异常。
package javax.xml.ws;
public class WebServiceException extends java.lang.RuntimeException {
public WebServiceException() {
super();
}
public WebServiceException(String message) {
super(message);
}
public WebServiceException(String message, Throwable cause) {
super(message,cause);
}
public WebServiceException(Throwable cause) {
super(cause);
}
}通过 throw 语句显式抛出异常, 显式抛出异常目的有很多,例如不想某些异常传给上层调用者,可以捕获之后重新显式抛出另外一种异常给调用者。
注意:throw 显式抛出的异常与系统生成并抛出的异常,在处理方式上没有区别,就是两种方法:要么捕获自己处理,要么抛出给上层调用者。在本例中是声明抛出,所以在 readDate()方法后面要声明抛出MyException异常。
一句话就是子类不能抛出更大的异常.
// 不要捕获异常而不处理
try {
someMethodThatMightThrow();
} catch(Exception e){
}
// 不要捕获,记录日志后再重新抛出异常
try {
someMethodThatMightThrow();
} catch(SpecificException e){
log(e);
throw e;
}第一个反模式直接忽略近乎一定需要处理的异常状况(甚至没有在日志中记录)。这么做会增大系统其他地方出现问题的可能性——出现问题的地方可能会离原来的位置很远。
第二个反模式只会增加干扰——虽然记录了错误消息,但没真正处理发生的问题——在系统高层的某部分代码中还是要处理这个问题。