java 异常处理

java语言中，Exception是所有异常的父类，任何异常都扩展于Exception类。

如果要定义一个新的错误类型，就要扩展一个新的Exception子类。采用异常可以精确的定位到导致程序出错的源代码位置,并获得详细的错误信息。

通过异常类，可以提供更为有用的错误信息，以便于用户进行跟踪和调试程序，降低了错误处理代码的复杂度。把正确的返回结果与错误信息分离，降低了程序的复杂度。调用者无需要对返回结果进行更多的了解。

 

有一个初学者容易忽略的概念：

Java异常分为两大类:checked 异常和unChecked 异常。

所有继承java.lang.Exception 的异常都属于checked异常，所有继承java.lang.RuntimeException的异常都属于unChecked异常。

(1)当一个方法去调用一个可能抛出checked异常的方法，必须通过try…catch块对异常进行捕获进行处理或者重新抛出。

(2)unChecked异常也称为运行时异常，通常RuntimeException都表示用户无法恢复的异常，如无法获得数据库连接，不能打开文件等。虽然用户也可以像处理checked异常一样捕获unChecked异常。但是如果调用者并没有去捕获unChecked异常时，编译器并不会强制你那么做。

 

使用checked异常会带来许多的问题，checked异常导致了太多的try…catch 代码。

可能有很多checked异常对开发人员来说是无法合理地进行处理的，比如SQLException。而开发人员却不得不去进行try…catch。

当开发人员对一个checked异常无法正确的处理时，通常是简单的把异常打印出来或者是干脆什么也不干。特别是对于新手来说，过多的checked异常让他感到无所适从。

 

checked异常导致了许多难以理解的代码产生当开发人员必须去捕获一个自己无法正确处理的checked异常，通常的是重新封装成一个新的异常后再抛出。这样做并没有为程序带来任何好处，反而使代码晚难以理解。就像我们使用JDBC代码那样，需要处理非常多的try…catch.，真正有用的代码被包含在try…catch之内。使得理解这个方法变理困难起来，checked异常导致异常被不断的封装成另一个类异常后再抛出

 

所以，使用原则是：

1.如果一个异常是致命的，不可恢复的，或者调用者去捕获它没有任何益处，使用unChecked异常。如果一个异常是可以恢复的，可以被调用者正确处理的，使用checked异常。

2.在使用unChecked异常时，必须在在方法声明中详细的说明该方法可能会抛出的unChekced异常，由调用者自己去决定是否捕获unChecked异常。

 

如何记录异常

作为一个大型的应用系统都需要用日志文件来记录系统的运行，以便于跟踪和记录系统的运行情况。系统发生的异常理所当然的需要记录在日志系统中。

异常应该在最初产生的位置记录！如果必须捕获一个无法正确处理的异常，仅仅是把它封装成另外一种异常往上抛出，不必再次把已经被记录过的异常再次记录。

如果捕获到一个异常，但是这个异常是可以处理的，则无需要记录异常。捕获到一个未记录过的异常或外部系统异常时，应该记录异常的详细信息。