2011-08-01 41 views

回答

4

Yes, they should

如果您知道的異常將總是可以通過自己的代碼捕獲,那麼OK使其internal

+0

但是該頁面說,如果「你確定只是私下使用的異常」,這是OP的斷言的一部分,可以壓制該規則。 – Sven

+0

並非如此:原因子句指出「非公共異常直接從** Exception,SystemException或ApplicationException派生**」。 – Vlad

0

它與範圍界定任何東西都是一樣的。一切都應該在適當的範圍內。

如果您在特定的類中創建了一個異常,並且只在該類內部使用該異常,那麼它應該只在該類內有一個範圍,因此它應該是私有的。但是,這並不常見。

第二個例外情況是將交給另一個對象調用你的類,你應該公開它。這是例外最常見的用法,因此大多數例外應該是公開的。

4

事實上,如果它們不是接口的一部分,那麼就有內部異常沒有什麼不好。這意味着,但是,這種

  • 要麼異常必須絕對不會越過你的模塊的邊界,
  • 或者你提供一個公共基礎例外,你的模塊的用戶可以趕上。

事實上,這是一個好主意,宣佈公共基本異常類型的模塊,讓用戶可以隨時依靠它在他們catch條款。如果你願意的話,從基類派生的單個異常可能是公開的,但可能不是那麼好。

請注意,您絕對不能依賴公共/私人機制來確保任何類型的安全性,因爲它可以通過簡單的反射輕鬆覆蓋。

0

想一想......這條鏈是多麼遙遠的異常?如果將從public函數拋出異常,那麼它應該是公開的。

也就是說,如果例外是總是在您的庫中捕獲並且不會拋出或重新貼上標籤並將其作爲別的東西拋出,它可以是內部的。

理想情況下,我有這樣的場景:

namespace MyAPI 
{ 
    public class PublicException : System.Exception 
    { 
    } 

    // derive my public exceptions from this 
    public class CatchableException : PublicException 
    { 
    } 

    // stuff that should never reach the users of my API 
    internal class InvisibleException : System.Exception 
    { 
    } 
} 

這樣一來,我的API的用戶有一個工廠趕任何例外,我扔。內部的人從來沒有那麼做過。