我正在处理消息库，并且对象的send方法可能由于多种原因而失败，例如套接字被关闭等。
我更喜欢检查运行时异常的异常，但我想知道是否更适合早期链接异常，以便底层异常总是包含在另一个更通用的异常中。
例如，邮件只能抛出已检查的SendFailedException，但cause()会更具体，例如SocketClosedException。这种感觉就像没有单独抛出所有检查过的异常一样混乱。
继承在这里不起作用，因为SocketClosedException也可以为其他方法抛出。并非每个已关闭的异常都是由于未能发送而造成的。
在cause()中包含更多信息是否合适？或者最终会更加混乱？我不记得发现在野外以这种方式运作的例外情况，这可能是非传统的并且让其他人感到困惑。
Java或其他库是否曾经这样做过？它适用于我的用例吗？
答案 0 :(得分：0)
在cause（）或中包含更多信息是否合适？ 这最终会让人更加困惑吗？
您始终可以使用cause来包装原始异常，该异常将提供有关堆栈跟踪中异常的根/原点的更多详细信息。您可以参考Exception API here，它解释了如何设置原因以包装异常。
Java或其他库是否曾经这样做过？它适合我的 用例？
在许多库中，遵循此模式，只是为了定位，在spring-mvc中，NestedServletException将被容器抛出，该容器将原因包装原始异常。是的，在您的情况下，您可以通过将原因设置为SendFailedException来抛出SocketClosedException。
此外，如果您的消息库来自第三方，请确保第三方Exception课程不会分散到您的项目/课程中，而是将其包装/转换为您自己的Exception类，这样您的代码就不会与第三方Exception类紧密结合（即使您必须从中迁移）。