Does it make sense to throw an exception which is always chained?
<p>I'm working on a message library and the send method of an object can fail for a number of reasons such as the socket being closed, etc.</p>

<p>I favor checked exceptions over runtime exceptions but I'm wondering if it would then be more appropriate to favor chaining the exceptions early such that the underlying exception is always wrapped in another, more generalized exception.</p>

<p>For example, a message may only throw a checked <code>SendFailedException</code> but the <code>cause()</code> would be more specific such as <code>SocketClosedException</code>. This feels like it would be less cluttered than having all of the checked exceptions being thrown individually.</p>

<p>Inheritance doesn't quite work here as a <code>SocketClosedException</code> can be thrown for other methods as well. And not every closed exception is a result of a failure to send.</p>

<p>Would it be appropriate to wrap further information in <code>cause()</code> or would this end up being more confusing? I don't recall finding exceptions functioning in this way in the wild and this might be unconventional and confusing for others.</p>

<p>Does Java or other libraries ever do this? Is it appropriate for my use case?</p>