用戶 輸入 不清楚 jvm 例子 的人 失敗 釋放 代碼

★空的 catch 語句塊

　　犯這種錯誤的人比較少，一般發生在剛學會 Java 或者剛參加工作不久的人身上。
　　所謂“空 catch 語句塊”就是在 catch 語句塊中沒有對異常作任何處理（比如記錯誤日誌），導致異常信息被丟棄/忽略。一旦程序不能正確運行，由於查不到任何 log 信息，只好從頭看代碼，靠肉眼找 bug。

★沒有使用 finally

　　很多人在 catch 語句之後不使用 finally 語句。由於在 try 語句中可能會涉及資源的申請和釋放。如果在資源申請之後、資源釋放之前拋出異常，就會發生資源泄露。

★籠統的 catch 語句塊

　　有些人為了省事，只在自己模塊的最外層代碼包一個 try 語句塊，然後 catch(Exception)。不管捕獲到什麽異常，都作統一 log 了事。這種做法比“空 catch 語句塊”稍好，但由於不能對具體的異常進行具體處理，對一些可恢復的異常（下面會提到），喪失了恢復的機會。而且也可能導致上述提到的資源泄露的問題。

★使用函數返回值進行錯誤處理

　　有些人放著 Java 的異常機制不用，而用函數返回值來表示成功/失敗（比如：返回 true 表示成功、false 表示失敗），簡直是“捧著金碗要飯”。個人感覺，從 C 轉到 Java 的人比較容易有此毛病。這種做法會導致如下幾個問題：
1. 返回值一般用整數值或布爾值表示，傳遞的信息過於簡陋；
2. 一旦調用者忽略了錯誤返回碼，就會導致和“空 catch 語句塊”類似的問題；
2. 對同一個函數的多處調用，都需要對返回值進行重復判斷，導致代碼冗余。

★不清楚“Checked Exception”和“Runtime Exception”的區別

　　這個現象比較普遍，俺發現很多2年以上 Java 工作經驗的人尚未完全搞明白兩者的區別。看來這個問題得詳細說一下。
當初Java的設計者有意區分這兩種異常，是別有深意的。其中“Checked Exception”用於表示可恢復的異常（也就是你必須檢查的異常）；而“Runtime Exception”表示不可恢復的異常（也就是運行時異常，主要是程序 bug 和致命錯誤，你【不需要】檢查）。不過這種做法引來了很多爭議（包括很多 Java 大牛），鑒於本帖子主要針對新手，以後再專門來聊這個爭議的話題。
　　為了便於理解，下面我舉一個例子來說明。假設你要寫一個 Download 函數，根據傳入的 URL（String 參數）返回對應網頁的內容文本。這時候有兩種情況你需要處理：

1. 如果傳入的 URL 參數是 null，這表明該函數的調用者出 bug 了，而程序本身的 bug 是很難在運行時自我恢復的。這時候 Download 函數必須拋出 Runtime Exception。並且 Download 函數的調用者【不應該】嘗試去處理這個異常，必須讓它【盡早】暴露出來（比如讓 JVM 自己終止運行）。
2. 如果傳入的 URL 參數非 null，但是它包含的字符串不是一個合法的URL格式（可能由於用戶輸入錯誤導致）。這時候 Download 函數必須拋出 Checked Exception。並且 Download 函數的調用者必須捕獲該異常並進行相應的處理（比如提示用戶重新輸入 URL）。

AJPFX談JAVA新手問題之異常處理使用不當