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