資訊專欄INFORMATION COLUMN
摘要：出現這種情況的可能性太多太多，例如服務器連接不上參數不正確等。調用代碼需要進一步處理和恢復。當然清理資源后，可以繼續拋出非檢測異常，阻止程序的執行。根據觀察和理解，檢測異常大多可以應用于工具類中。
異常的選擇“唵”，表示佛部心，謂念此字時，自己的身體要應于佛身，口要應于佛口，意要應于佛意，所謂身、口、意與佛成一體，才能獲得成就；
異常的分類,你應該知道:
受審查異常
非受審查異常
發現學生在使用過程當中,沒有區分,也不知道應該什么時候使用?跟不清楚怎么樣合理的使用異常!
我再后面接手的課程體系當中,學生如果在使用異常的情況下,最愛的是Exception,怎么解釋呢,簡單好用?只能心里默默的呵呵!而作為一名開發人員使用比較多的是非受審查異常[繼承RuntimeException]!往往這個時候,學生就懵圈了,為什么呢?因為看不到錯誤了,不知道哪里錯了!
心在滴血,因為給自己增加了難度,何必難為自己嫩?
那么,如何使用異常呢?簡單說一下個人的理解:
調用或者執行的代碼不能繼續執行，需要立即終止。出現這種情況的可能性太多太多，例如服務器連接不上、參數不正確等。這些時候都適用非檢測異常，不需要調用代碼的顯式捕捉和處理，而且代碼簡潔明了。
調用代碼需要進一步處理和恢復。假如將 SQLException 定義為非檢測異常，這樣操作數據時開發人員理所當然的認為 SQLException 不需要調用代碼的顯式捕捉和處理，進而會導致嚴重的 Connection 不關閉、Transaction 不回滾、DB 中出現臟數據等情況，正因為 SQLException 定義為檢測異常，才會驅使開發人員去顯式捕捉，并且在代碼產生異常后清理資源。當然清理資源后，可以繼續拋出非檢測異常，阻止程序的執行。根據觀察和理解，檢測異常大多可以應用于工具類中。
胖先生說一下:
讓機器自己去處理,我們不管!
就是我們需要捕獲并且自己處理
別把客戶想的太聰明在實際開發當中,胖顯示都會把受審查變成非受審查的,但是同時我根據自己的業務需要進行處理!
將異常直接打印在客戶端的例子屢見不鮮，以 JSP 為例，一旦代碼運行出現異常，默認情況下容器將異常堆棧信息直接打印在頁面上。其實從客戶角度來說，任何異常都沒有實際意義，絕大多數的客戶也根本看不懂異常信息，軟件開發也要盡量避免將異常直接呈現給用戶。
客戶都是比較懶的人,如果出現那種文字,站在你的角度,我想會感覺到厭惡,考察我英語四級能力呢?
package com.pangsir.test.sample.exception;
/**
* 自定義 RuntimeException
* 添加錯誤代碼屬性,一種簡單的封裝
*/
public class RuntimeException extends java.lang.RuntimeException {
//默認錯誤代碼
public static final Integer GENERIC = 1000000;
//錯誤代碼
private Integer errorCode;
public RuntimeException(Integer errorCode, Throwable cause) {
this(errorCode, null, cause);
}
public RuntimeException(String message, Throwable cause) {
//利用通用錯誤代碼
this(GENERIC, message, cause);
}
public RuntimeException(Integer errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
}
public Integer getErrorCode() {
return errorCode;
}
}
正如示例代碼所示，在異常中引入錯誤代碼，一旦出現異常，我們只要將異常的錯誤代碼呈現給用戶，或者將錯誤代碼轉換成更通俗易懂的提示。其實這里的錯誤代碼還包含另外一個功能，開發人員亦可以根據錯誤代碼準確的知道了發生了什么類型異常.
別玷污我我們授課當中經常說基于MVC思想的開發架構,因此我們將代碼分為controller,Service,Dao等不同的層次,Dao層中經常會拋出異常的方法[因為不熟練,因為SQL語句經常寫錯誤],都是過來人:
Dao層代碼:
public User load(Integer user_id) throw SQLException {
//根據 ID 查詢數據庫,獲取用戶對象信息
}
如果代碼是這樣寫的,沒有什么問題,可以說正確,但是不符合規范!
從設計耦合角度仔細考慮一下，這里的 SQLException 污染到了上層調用代碼，調用層需要顯式的必須利用 try-catch 捕捉 或者 向更上層次繼續拋出。根據隔離原則，我們可以適當修改成：
public User load(Integer user_id) {
try{
//根據 ID 查詢數據庫
}catch(SQLException e){
//利用非檢測異常封裝檢測異常，降低層次耦合
throw new RuntimeException(SQLErrorCode, e);
}finally{
//關閉連接，清理資源
}
}
別不在乎我的感受
在學生開發當中,也可以說我為了圖省事的過程當中,經常說的一句話就是你把異常輸出[打印]控制臺中,其實這樣沒有任何意思!
重要|重要|重要:
這樣的處理沒有意思,因為你沒有中斷程序的執行,進而調用代碼會繼續自行,導致更多的異常
想想你是否寫過這樣的代碼:
public void update(User user){
try{
//..some code that throws SQLException
}catch(SQLException ex){
/**
*了解的人都知道，這里的異常打印毫無意義，僅僅是將錯誤堆棧輸出到控制臺。
* 而在 Production[生產] 環境中，需要將錯誤堆棧輸出到日志。
* 而且這里 catch 處理之后程序繼續執行，會導致進一步的問題
* */
ex.printStacktrace();
}
}
代碼重構
public void update(User user){
try{
//..some code that throws SQLException
}
catch(SQLException ex){
//轉換成非受審查異常
throw new RuntimeException(“自己描述性語言,例如com.pangsir.user.dao.UserDao.update 執行過程出錯”, ex);
}
finally{
//關閉資源
}
}
地主家也沒有余糧這個誤區比較基本，一般情況下都不會犯此 > 低級錯誤 < 。
看一下,下面的代碼是否有問題?
