重新拋出異常好習慣嗎？

Question

你認爲捕捉異常並重新拋出它是一種很好的做法嗎？

基本上我有一段代碼，其中使用3個參數的構造函數創建一個顏色。顏色構造函數可能會拋出異常。

public PointExtend(double x, double y, int r, int g, int b) 
     : base(x, y) 
    { 
     try 
     { 
      var color = new Color(r, g, b); 
      Color = color;     
     } 
     catch (InvalidColorValueException) 
     { 
      throw; 
     } 
    } 

ReSharper的說，漁獲擲條款是多餘的，我同意，考慮到我沒有做任何不同之處，但再次拋出它，如果我不是，它會泄漏無論如何UI，但是，這不是」這段代碼讓程序員更容易閱讀，所以如果他創建了PointExtend，他會知道代碼可能拋出什麼？

Answer 1

如果您希望程序員知道某些使用註釋。 捕捉和拋出異常是一種開銷，並且是無用的（除非你在重拋之前對它做了什麼，例如記錄它），所以程序員實際上會感到困惑，認爲存在一個bug並且不理解最初的意圖是什麼。

Answer 2

正如你所說，上面代碼中的throw是毫無意義的，所有運行時將會做的只是重新拋出相同的異常。你可以刪除try catch，它的功能是一樣的。

如果你對異常本身做了某些事情，那就是抓住它的原因，否則就讓它冒出來，給用戶一個有意義的消息，把它記錄在錯誤日誌中，然後你就不會給用戶一個廢話異常彈出:)

Answer 3

除非你正在做任何特定的日誌記錄或異常包裝，你可以刪除它。

如果你想在程序員知道約可能是個例外，其記錄下來：

/// <summary> 
/// Creates a new instance of <code>PointExtend</code> 
/// </summary> 
/// <param name="x">...</param> 
/// <param name="y">...</param> 
/// <param name="r">...</param> 
/// <param name="g">...</param> 
/// <param name="b">...</param> 
/// <exception cref="InvalidColorValueException">Should the provided rgb values be out of range</exception> 
public PointExtend(double x, double y, int r, int g, int b) 
     : base(x, y) 
    {    
      var color = new Color(r, g, b); 
      Color = color;        
    } 

這將允許其消耗你的API其他程序員知道什麼是構造函數和任何潛在的缺陷。不是每個人都可以訪問你的代碼。

編輯：根據@Philip Stuyck的評論，儘管我同意，但我認爲我們並不生活在理想的世界。您推薦的問題是：

• 如果您需要發送DLL的混淆版本，會發生什麼情況？這通常發生在公司銷售其DLL時。您無法真正查看代碼，而方法名稱只能走得這麼遠。
• 大多數項目往往不僅僅是少數幾個類，而且每次通過代碼來弄清楚發生了什麼會花費很多時間，並且可能使人們無法使用您的產品。在我看來，開源項目是this的一個明確例子。
• 最後，更重要的是，在我看來，您說的代碼所做的唯一部分是摘要部分（至少對於.NET而言）。評論和文件應該揭示爲什麼是一個選定的方法。

Answer 4

你真的從這裏試圖說服你，你應該記錄你的代碼的人不好的建議。

只有寫得不好的代碼才需要註釋，而不是花時間撰寫評論和評論，在代碼中花費這些努力，以便它根本不需要評論。

這是否意味着所有評論都是邪惡的。不，當然不。有些情況下仍然需要評論，因爲編程語言並不總是最適合描述發生的事情。但即使如此，也必須小心謹慎，因爲評論將開始過上自己的生活。

http://apdevblog.com/comments-in-code/

是由羅伯特C.馬丁

指清潔守則博客中有一個在這本書有關的評論整整一章，那些誰認爲你需要更好的註釋讀了書。

在你的具體情況下，如果你真的覺得代碼更好，當你趕上例外，然後重新拋出沒有額外的，通過一切手段讓它進入。 個人我會離開它。但對我來說，這只是一個風格問題。與同事達成協議，並在團隊中保持一致。

我在這裏的答案可能會引起很大的爭議，你對這個問題都有自由意見。 （羅伯特馬丁說同樣的事情;-)）但事實是，在很多情況下，評論只是混淆了代碼並降低了可讀性。評論被遺忘更新，因此不再與真實代碼內聯，...

另一種記錄所有事情的方法是編寫好的單元測試。通過閱讀單元測試的代碼，如果它們寫得很好，你將會明白代碼應該如何使用。那就是如果你正在寫一個API供其他人使用。

寫得很好的代碼也很好地分層，不需要在系統中的每一個類中進行分解。如果你必須這樣做才能理解代碼，那麼結論也是一樣的。這是錯誤的代碼。

方法名稱和變量名稱，類名稱走得很遠。在閱讀完整代碼之後，我大大改變了我的代碼風格。

我寫軟件已有20年了，我已經看到了，寫了很多評論。在很多情況下，他們仍然不清楚他們在評論中的真正含義，或者評論僅僅是錯誤的。