catch塊之後的代碼是壞的還是無意義的？

我在問一個簡單的問題。在catch塊之後有任何代碼是不好的。即我們是否需要將它們包含在try中，然後在catch中重新拋出一個包裝異常呢？catch塊之後的代碼是壞的還是無意義的？

我不是在問最後的操作。

讓我們舉個例子吧。在這裏，doSomething（）方法會拋出一個名爲'SomeException'的異常。

代碼1：

try{ 
doSomething(); 
}catch(SomeException e){ 
    throw new AnotherException(e); 
} 
doAnotherThing(); 
return someResult;

碼2：

try{ 
    doSomething(); 
    doAnotherThing(); 
    return someResult; 
}catch(SomeException e){ 
    throw new AnotherException(e); 
}

在上面的兩個例子，是否有任何代碼2加點？

來源

2016-08-04 Supun Wijerathne

@DaveNewton你能否詳細解答一下答案？ –

有如果doSomething()沒有發生異常，則2個案例之間存在差異，但是doAnotherThing()會拋出SomeException。

SomeException將在代碼進一步上propated。
SomeException將由catch塊被捕獲並進一步重新拋出AnotherException。

另一個需要考慮的情況是catch塊不重新拋出異常。

將執行doAnotherThing()
不會。

因此，正如其他答案中已經指出的那樣，每行有1個try-catch塊會使您的代碼更清晰並避免意外的行爲。在另一方面，我會考慮分組在同一塊多行，當你有這樣的事情

try { 
    doSomething(); // can throw SomeException 
    doAnotherThing(); 
    doSomething(); // can throw SomeException as well 
    return someResult; 
} catch(SomeException e) { 
    throw new AnotherException(e); 
}

這使得SENS如果我們不關心它是否是第一或doSomething()第二個呼叫拋出異常我們不在乎是否調用doAnotherThing()。

來源

2016-08-04 17:15:24 noscreenname

你已經在很寬的範圍內解釋過了。很好的工作。 :) –

關於「壞」的判斷對我來說是主觀的。

我的選擇是每一個方法的try/catch，與在嘗試所有代碼。

編譯器不會阻止你在catch之後放置代碼。我會在代碼審查中引用你。

來源

2016-08-04 11:32:54 duffymo

你的偏好是什麼原因？ :) –

個人品味，可讀性，源代碼看，乾淨的代碼，一個方法做好一件事的概念。當我看到代碼在方法內部晃動時，感覺混亂和泥濘。我將try/catch塊重構爲一個方法調用。我可能會把那些亂七八糟的東西推到捕捉塊之後，並且制定一種方法。這是馬虎。 – duffymo

推力？！你的代碼與我的代碼不同;） –

風格2的一個問題，你把更多的代碼在try塊，它可以趕上意外，你沒有想到在那裏，特別是當它是一個相當高的水平異常或運行時異常的異常。假設你試圖將一個字符串轉換爲數字，並且正在捕獲可能的NumberFormatException。因此，假設樣式2，您使用DoAnotherThing執行更多的代碼。也許你甚至在打電話給圖書館。現在這個庫引發了相同的異常，但是你正在處理它，就像它來自你自己的代碼。

出於這個原因，我更喜歡小try/catch塊，除非我真的知道這一點是繼代碼的其餘部分。但是，當然，這取決於你實際上是（從你顯然不會在其他地方調用拋出一個有圖書館一個自定義）捕捉異常了很多和代碼的可讀性，等等，等等

來源

2016-08-04 15:26:21

catch塊之後的代碼是壞的還是無意義的？

回答

相關問題