Making AssertError a singleton
Jonathan M Davis via Digitalmars-d
digitalmars-d at puremagic.com
Tue Dec 13 14:46:53 PST 2016
On Tuesday, 13 December 2016 at 06:36:47 UTC, Shachar Shemesh
wrote:
> On 13/12/16 02:57, Andrei Alexandrescu wrote:
>>
>> You can catch AssertError. There's no guarantees dtors have
>> been called
>> during unwinding. -- Andrei
>
> That makes no sense to me, unless you only want to catch it in
> order to do something right before exiting anyways.
>
> Also, please note that not all non-Exception Throwables are
> terminal for the process. We use a Throwable that is not an
> Exception in order to force termination of a fiber from outside
> in a clean way. If proper unwinding is not guaranteed under
> this condition, we have a problem.
_Errors_ do not guarantee that the stack is unwound properly.
It's been Walter's stance for years that it's bad for the program
to do any cleanup when an Error is thrown and that it's not
guaranteed that the cleanup happens. However, someone working on
the exception stuff at one point _did_ make it so that the
cleanup is always done (which Walter doesn't like but hasn't
fixed). So, for code that doesn't use nothrow, Errors currently
result in full cleanup but it's not actually, officially
guaranteed that it will, and it could change in the future
(though that would be a problem in the case of AssertError for
contracts and unittest blocks).
For nothrow code, it _is_ currently the case that full cleanup
doesn't necessarily happen when an Error is thrown, because the
compiler doesn't emit the exception stuff for nothrow functions.
As for Throwable, I think that it's mostly ignored and not really
thought about in discussions like this. Most everything is either
an Exception or an Error. So, I don't know what Walter would say
about it. However, Throwables do _not_ work with nothrow. This
function
void func() nothrow
{
throw new Throwable("blah");
}
will fail to compile. That being the case, it would seem that
Throwables are treated more like Exceptions than Errors, which
implies that you're fine, but Walter would have to weigh in to be
sure. Part of the question probably comes down to when it's valid
to derive from Throwable directly, which it rarely is. But I
don't think that it would be hard to convince Walter that you
have a valid use case that requires that Throwable clean up
correctly and that only Errors should not do proper cleanup -
particularly since the whole reason that Errors don't guarantee
full cleanup is because it's an unrecoverable error condition,
and if a Throwable is an unrecoverable error condition, it really
should be derived from Error, not Throwable.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list