異常是否破壞封裝？

Question

首先，當您不想擔心實現的細節時，會創建一個類或庫，但是您需要知道該類的內部工作方式，以正確處理它可能拋出的異常。

這是否違背了封裝和信息隱藏的原則？或者我完全錯了嗎？

當然，我可以有一個通用的try/catch塊攔截所有的異常，但這絕對是一個不好的做法。

那麼，如何在不知道可能引發的每個異常的細節的情況下提出良好的異常處理策略呢？

Answer 1

設計良好的類或庫將記錄它作爲接口的一部分拋出的異常，甚至可能甚至可以定義自己的異常類層次結構。例如，如果磁盤已滿，foo子類可能會拋出「foo持久性異常」，而另一個子類會在網絡關閉時拋出一個。作爲調用者，您會捕獲一個foo持久性異常，因爲您擔心數據未被保留。不應期望您編寫專門用於磁盤滿，網絡關閉，磁盤不存在，磁盤寫入錯誤，子空間收發器干擾的代碼，& c。

可能出現這種情況，您不能對其中的很多事情做很多事情。

Answer 2

這不是那樣的;它適用於使用最終產品的最終用戶或者「不需要知道內部實現」的類，但是您肯定知道它，因此可以相應地糾正錯誤機制。

順便說一句，這就是任何API帶有良好文檔的原因......所以其他開發人員至少知道它的一些內部工作。

希望這清除了這個想法。

Answer 3

類庫不必拋出其代碼拋出的相同異常。對於無法在內部處理的預期異常，它應該映射到備用異常類型，API消費者不容易理解「原始」異常。 API消費者應該能夠將預期的異常視爲API的輸出，正如API的任何其他使用產品一樣。另一方面，意想不到的例外是API開發人員和消費者的另一種蠟燭......

Answer 4

首先，一類或庫創建時你不想 擔心的實施細節，但你需要 知道類妥善處理異常的內部運作 它可能會拋出。

這是不是破壞了封裝和信息隱藏的原理 ？或者我完全錯了嗎？

如果由於某些運行時錯誤而導致無法履行其承諾，並且無法從該狀態恢復，則應引發異常。必須在接口/文檔中指定可能拋出什麼異常。我不明白這是如何破壞封裝的。另一方面，使用返回碼不能強制調用者處理特殊錯誤，即使通過明確忽略它。

當然，我可以有一個通用的try/catch塊來攔截所有異常，但這絕對是一個不好的做法。

這是如果你使用沒有明確地指出可能會被拋出異常是什麼接口的設計以及由誰/ what_function

所以，我怎麼能拿出良好的異常處理策略沒有 知道可能引發的每個異常的詳細信息？

「細節」實際上是例外規範，這就是你所需要知道的。同樣，它應該是文檔/界面的一部分。

無論如何，異常應該很少發生，也許這就是爲什麼有人給它們命名爲異常。如果它發生得太頻繁，那麼有人不會再將它們命名爲例外，但「平常」或其他事情以及正常，無異常的「代碼」將成爲例外:)

如果您工作太多，/catch bollocks，那麼代碼有問題。