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