The Proper Use of Exception Chaining: Caught between two conflicting usecases?

Meta jared771 at gmail.com
Thu May 2 18:34:39 UTC 2019


On Thursday, 2 May 2019 at 07:10:45 UTC, FeepingCreature wrote:
>> Case 2 is the intended use for chained exceptions. It's an 
>> answer to the question of "what happens if you throw an 
>> exception while another one is already in flight?" In the case 
>> of C++, the program is immediately aborted. In D's case, the 
>> second exception will be chained onto the first one.
>
> Okay, but then that first of all contradicts the documentation 
> at https://dlang.org/library/object/throwable.next.html

I don't understand how what I said contradicts what's on that 
page. It seems to agree with what I said, from what I can tell:

A reference to the next error in the list. This is used when a 
new Throwable is thrown from inside a catch block. The originally 
caught Exception will be chained to the new Throwable via this 
field

> ...and second of all there's still very much a call for being 
> able to react to an exception by throwing an exception of 
> another type, without losing the first exception's stack trace.

I completely agree; this feature is invaluable in figuring out 
what went wrong when looking at a stack trace.

> Currently if we catch three types of exceptions that happen 
> somewhere in Phobos and rethrow them as some generic or domain 
> exception, the error will appear to come from the exception 
> handler. Does the error come from the exception handler? No! 
> The actual source of the error has been completely obfuscated. 
> This is bad!

Again, agreed. My only disagreement is over what Throwable.next 
is intended to be used for.



More information about the Digitalmars-d mailing list