何時使用Try Catch(轉)

幾條建議：
　　 若是沒法處理某個異常，那就不要捕獲它。 
　　 若是捕獲了一個異常，請不要胡亂處理它。 
　　 儘可能在靠近異常被拋出的地方捕獲異常。 
　　 在捕獲異常的地方將它記錄到日誌中，除非您打算將它從新拋出。 
　　 按照您的異常處理必須多精細來構造您的方法。 
　　 須要用幾種類型的異常就用幾種，尤爲是對於應用程序異常。
　　 把低層次的異常封裝成層次較高程序員較容易理解的異常。
　　 儘可能輸出形成異常的完整數據
　　 儘可能捕獲具備特定含義的異常：好比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的輸出。