抛出一个总是被链接的异常是否有意义？答案

【问题标题】：Does it make sense to throw an exception which is always chained?抛出一个总是被链接的异常是否有意义？
【发布时间】：2016-12-03 11:22:59
【问题描述】：

我正在开发一个消息库，对象的 send 方法可能由于多种原因而失败，例如套接字被关闭等。

我更喜欢检查异常而不是运行时异常，但我想知道是否更适合早期链接异常，这样底层异常总是包装在另一个更通用的异常中。

例如，一条消息可能只抛出一个选中的SendFailedException，但cause() 会更具体，例如SocketClosedException。感觉它比单独抛出所有检查的异常要少。

继承在这里不太有效，因为 SocketClosedException 也可以用于其他方法。并不是每个关闭的异常都是发送失败的结果。

将更多信息包含在cause() 中是否合适，或者这最终会更加混乱？我不记得在野外发现以这种方式运行的异常，这可能是非常规的并且对其他人来说是混乱的。

Java 或其他库是否曾经这样做过？它适合我的用例吗？

【问题讨论】：

几乎每个带有正常检查（或未检查）异常的库都通过继承定义了自己的异常层次结构。每当有需要重新抛出的异常时，都应该将其用作原因，原因就是它的用途。
And not every closed exception is a result of a failure to send.你能举个例子什么关闭的异常不是发送失败？
关闭后尝试从套接字查询无效状态时可能会引发关闭异常。

标签： java exception exception-handling

【解决方案1】：

将更多信息包含在 cause() 中是否合适？这最终会更令人困惑吗？

您始终可以使用cause 来包装原始异常，这将在堆栈跟踪中提供有关异常根/源的更多详细信息。您可以参考 Exception API here，它解释了如何设置原因来包装异常。

Java 或其他库是否曾经这样做过？是否适合我的用例？

在许多库中，都遵循这种模式，只是为了指出，在 spring-mvc 中，NestedServletException 将被容器抛出，该容器将用原因包装原始异常。是的，在您的情况下，您可以通过将原因设置为SocketClosedException 来抛出SendFailedException。

另外，如果您的 消息库 来自第三方，请确保第三方 Exception 类不会分布在您的项目/类中，而是将它们包装/转换为您自己的 @987654327 @classes，这样您的代码就不会与第 3 方 Exception 类紧密耦合（即使您必须从中迁移）。

【讨论】：