拋出一個始終鏈接的異常是否有意義？

我正在處理一個消息庫和一個對象的發送方法可能由於多種原因，如套接字被關閉等失敗等。拋出一個始終鏈接的異常是否有意義？

我喜歡檢查異常超過運行時異常，但我想知道是否那麼應該更早地支持異常鏈接，這樣基礎異常總是被包含在另一個更普遍的異常中。

例如，一條消息可能只會拋出檢查的SendFailedException，但cause()會更具體，如SocketClosedException。這感覺就像它比單獨拋出所有檢查過的異常要少得多。

由於其他方法也可以拋出SocketClosedException，所以繼承並不適用於此。並非每個關閉的異常都是未能發送的結果。

將cause()中的進一步信息包裹起來會不會更合適？我不記得在野外發現以這種方式運作的例外情況，這可能是非常規的，並且讓其他人感到困惑。

Java或其他圖書館是否曾經這樣做？對我的使用情況適合嗎？

2016-12-03 Zhro

幾乎每個具有正常檢查（或未檢查）異常的庫都通過繼承來定義它們自己的異常層次結構。每當需要重新拋出一個異常時，它應該被用作原因，因爲這是它的目的。 – zapl

'並不是每個關閉的異常都是發送失敗的結果。「你能舉出一個例子：關閉的異常不是無法發送的嗎？ –

嘗試在關閉後從套接字查詢無效狀態時，可能會拋出關閉的異常。 – Zhro

將cause（）或這些結果變得更加混淆是否合適？

您始終可以使用cause來包裝原始異常，該異常將提供有關堆棧跟蹤中異常的根/原點的更多詳細信息。您可以參考異常API here，它解釋瞭如何設置原因來包裝異常。

Java或其他圖書館是否曾經這樣做？是否適合我的用例？

在許多庫，這種模式是其次，只是針點，在彈簧-MVC，NestedServletException將通過將包裝與原因原始異常的容器被拋出。是的，就你而言，你可以通過將原因設置爲SocketClosedException來拋出SendFailedException。

另外，如果您信息庫是來自第三方，確保第三方Exception類不會在你的項目/類傳播，而包裹/把它們轉換成自己的Exception類，這樣你的代碼是不是與第三方Exception類緊密結合（即使您必須從中遷移）。

2016-12-03 11:49:56 developer

回答