長試語句

Question

是否有任何缺點將您的函數的大部分代碼放在try statement中。如果我做的事情需要try statement，我通常最終會在try語句中爲該函數做很多工作，因爲我通常在那裏聲明我的變量，如果我這樣做，就不能在該範圍外使用它們。這是常見的並被接受嗎？人們通常在不初始化的情況下聲明變量，因此他們不會在try statement內部做所有事情（包括調用其他函數）？或者它是否很長很重要？

Answer 1

一種方法應該做一件事，做得好。在這種情況下，你的方法是做兩件事情：業務邏輯和錯誤處理：

public Foo bar() { 
    try { 
     //business logic that may throw 
     //... 
     //end even more 
    } catch(BuzzException e) { 
     //Error handling 
    } 
} 

很多時候，我發現自己提取try塊的內容到一個單獨的方法沒有錯誤處理：

public Foo bar() { 
    try { 
     return unsafeBar(); 
    } catch(BuzzException e) { 
     //Error handling 
    } 
} 

public Foo unsafeBar() throws BuzzException { 
    //business logic that may throw 
    //... 
    //end even more 
} 

Answer 2

它如果它很長很重要，但不是因爲你的想法。這很重要，因爲它會讓您的代碼難以閱讀和測試。你最好是重構幾種方法：

public void doComplexThing() { 
    try { 
     SomeObject o1 = doSomethingLessComplex(); 
     SomeOtherObject o2 = doSomethingElse(o1); 
     doFinalThing(o2); 
    } 
    catch (SomeException e) { 
     // handle the exception 
    } 
} 

Answer 3

如果try塊開始有點長，這是一個好主意，這實際上是扔異常轉換成自己的方法的調用隔離。這樣你就可以單獨處理可能在該塊中拋出的幾種異常。

如果您正在嘗試測試或發現「神祕」錯誤，那麼在try中覆蓋很多例外情況，而舊式的catch(Exception ex)會引起頭痛。這並不是說正確的資源/流處理，這是許多檢查異常的東西。

Answer 4

作爲一名高級程序員，我理解使用try catch完全勝過拋出異常的代碼與代碼整齊性之間的混淆。

在這裏，我會傾向於try catch over the statements that need it。

首先讓我們瞭解嘗試捕捉的必要性。因爲我們想在這裏和現在處理它，所以我們捕獲異常。如果我們不把它扔給調用者。我們扔掉它，以便我們不會忘記稍後處理它。從來沒有，Oh!, let me finish this method and then I will worry about the exception handling later。當你編碼的時候這樣做，想想，你需要打印一個錯誤並返回null，還是你需要用戶知道某些事情搞砸了？你是否想將所有連接問題整合到recycle the connection有點消息？如果是，那麼拋出你自己的自定義異常。但一定要處理它。忽略和執行錯誤的異常處理是項目維護和客戶心臟燒傷成本增加的根本原因。這是一個好產品和一個草率產品的區別。

至於代碼整潔，我發現在catch塊的評論使它值得你一會兒。是的，會有一位高級的人不理解捕捉確切聲明的重要性，並且會直接抓到catch (Exception e)。可悲，我會說。但是當你編碼時，你應該堅持你的道德觀。做對，做一次。