幾條建議：
如果無法處理某個異常，那就不要捕獲它。
如果捕獲了一個異常，請不要胡亂處理它。
儘量在靠近異常被拋出的地方捕獲異常。
在捕獲異常的地方將它記錄到日誌中，除非您打算將它重新拋出。
按照您的異常處理必須多精細來構造您的方法。
需要用幾種類型的異常就用幾種，尤其是對於應用程序異常。
把低層次的異常封裝成層次較高程序員較容易理解的異常。
儘量輸出造成異常的完整數據
儘量捕獲具有特定含義的異常：比如SqlException，而不是簡單地捕獲一個Exception。
如果你的程序不是對效率苛求得過分，我建議你寧可多使用一些異常也是好的。
注意：我說的多使用的意思不是讓你全部trycatch起來，然後catch(Exception e)把所有的異常都屏蔽了；而是暫時不考慮trycatch可能帶來的效率上的損失，而注重程序的穩定性。
至於如何優化trycatch的使用，慢慢來。就我個人的使用而言，影響其實不是很大。
1. 不要濫用Try…Catch。一般來說只在最外層函數上才需要。因爲該函數不能將Exception再往外拋了。所以需要Catch住做相應的處理，如顯示Error Message。或轉化爲與調用模塊約定好的Error Code。內部函數即使Catch住了Exception，也要往外拋，所以沒有必要。
2. 爲了使用Finally來保證資源的釋放。如：
SqlConnection connection = null;
try
{
connection = new SqlConnection(ConnectionString);
connection.Open();
…
}
catch (Exception ex)
{
throw ex;
}
finally
{
if (connection != null && connection.State != ConnectionState.Closed)
{
connection.Close();
}
}
對這種情況Catch住的Exception直接往外拋，不做處理。需要注意的是這裏使用Try…Catch不是唯一的辦法，也可以使用using語句來保證資源的釋放。
3. 爲了保證函數有統一的出口。比如一個最外層的函數連續調用了一系列內部子函數，當其中某個子函數出錯時， 跳到函數最後退出，對這種情況Catch住的Exception直接吃掉，因爲在Try裏面已經做了錯誤處理。如：
public Result OutMostFunction()
{
Result result = Result.Success;
try
{
try
{
SubFunction1();
}
catch (Exception ex)
{
result = Result.SubFunction_1_Error;
throw ex;
}
try
{
SubFunction2();
}
catch (Exception ex)
{
result = Result.SubFunction_2_Error;
throw ex;
}
try
{
SubFunction3();
}
catch (Exception ex)
{
result = Result.SubFunction_3_Error;
throw ex;
}
}
catch (Exception ex)
{
}
return result;
}
4. 爲了區分程序錯誤與邏輯錯誤，需要自定義一個Exception類型。比如一個最外層函數調用一個密碼驗證子函數，就需要區分是因爲密碼錯誤（邏輯錯誤），還是在密碼驗證過程中程序出現了沒有預料到的錯誤（程序錯誤）。如：
public class GoOutException : Exception {}
public Result OutMostFunction()
{
Result result = Result.Success;
try
{
try
{
if (!VerifyPassword(password))
{
result = Result.Invalid_Password;
throw new GoOutException();
}
}
catch (Exception ex)
{
if (!(ex is GoOutException))
{
result = Result.General_Error;
}
throw ex;
}
}
catch (Exception ex)
{
}
return result;
}
- 什麼時候使用try catch語句模塊，是不是沒有明確的答案？
- 來自網友的回答：try catch是程序語言本身提供的一種異常處理機制，你大多數寫的代碼都是要調用底層的api，而這些api的作者在開發api時，很清楚api在使用的過程中會有哪些非正常情況發生，因此他要通知api的調用者，至於對於這種非正常情況怎麼處理，就交給了api的調用者。
- 你是寫代碼的，你要調用api，因此你就說api的調用者，你也應該處理api本身存在的非正常情況，那你怎麼處理這些非正常狀況，這就是你提到的try catch的作用了，它就是幹這事的。至於api會有哪些非正常情況發生，需要查api的幫助文檔；這些非正常狀況怎麼處理，這又取決於問題邏輯了，跟實際需求有關係。
- try{A程序塊} catch{Exception e}{B程序塊} 。。。。。
- A程序塊比較有可能會出錯的地方，B則是如果A中有了錯誤，進行的處理。就好比，一個流水線上，如果有個地方有個產品堵住了不通了，如果沒人處理，則整個流水線就沒法動作了，要想保證整個流水線的運作則要有人把這個產品給處理了。try語句就是對A程序塊的語句進行捕捉有可能出錯的地方，相當於流水線上那個檢查的人，catch語句則是處理的.
- 什麼情況下需要用try-catch呢，那就是不使用這種try結構時，代碼報錯退出就無法繼續執行。有的代碼出錯就應該退出，有的出錯尚可以補救，就不應該退出。對於這種出錯不應該退出的就需要使用這種結構，在catch中進行補救。例如，寫入一個日誌文件，如果這個日誌文件被鎖定或者佔用，那麼寫入就會出錯退出，但是我們並不想看到這樣的情況，我們完全可以換一個名字再寫入。
- 有的函數或者功能調用之後不會出錯退出，但是會返回錯誤碼，這個時候也不需要使用try-catch結構。直接根據不同的錯誤碼進行分類處理就行了。
- 所以不是trycatch使用量的問題，還是看應用場景，如果確實需要防止異常退出，需要多次補救，那麼再多都是不爲過的。
- 還有一個情況要注意，try-catch不是能夠解決所有的出錯退出，例如php中的segment fault，也就是熟知的段錯誤，就算是try-catch了也還是會退出，這個時候需要使用gdb進行調試解決了。
- try catch後是不是一定要輸出異常信息？或者有沒有更好的辦法去處理日誌信息呢？
- 如果每一段程序都try catch後輸出日誌，會導致日誌信息臃腫不堪，無法從日誌中讀取有用的信息，使得解決問題更加困難。那有沒有統一處理日誌信息的工具包呢！規劃好日誌信息，異常信息將更加清晰明瞭，同時多讀日誌可以不段優化程序減少異常的發生情況，一舉多得何樂而不爲!
- LOG4J學習
- 定義：Log4j是Apache的一個開放源代碼項目，通過使用Log4j，我們可以控制日誌信息輸送的目的地是控制檯、文件、GUI組件、甚至是套接口服務器、NT的事件記錄器、UNIX Syslog守護進程等；我們也可以控制每一條日誌的輸出格式；通過定義每一條日誌信息的級別，我們能夠更加細緻地控制日誌的生成過程。最令人感興趣的就是，這些可以通過一個配置文件來靈活地進行配置，而不需要修改應用的代碼。
- 程序開發環境中的日誌記錄是由嵌入在程序中以輸出一些對開發人員有用信息的語句所組成。例如，跟蹤語句（trace），結構轉儲和常見的 System.out.println或printf調試語句。log4j提供分級方法在程序中嵌入日誌記錄語句。日誌信息具有多種輸出格式和多個輸出級別。
- 使用一個專門的日誌記錄包，可以減輕對成千上萬的System.out.println語句的維護成本，因爲日誌記錄可以通過配置腳本在運行時得以控制。 log4j維護嵌入在程序代碼中的日誌記錄語句。通過規範日誌記錄的處理過程，一些人認爲應該鼓勵更多的使用日誌記錄並且獲得更高程度的效率。
- 使用log4j大概涉及3個主要概念:
- 公共類 Logger Logger 負責處理日誌記錄的大部分操作。
- 公共接口 Appender Appender 負責控制日誌記錄操作的輸出。
- 公共抽象類Layout Layout 負責格式化Appender的輸出。