[Issue 19602] Under some circumstances: throwing Error subclasses unwinds without invoking dtors

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19602

Walter Bright <bugzilla at digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla at digitalmars.com
         Resolution|---                         |WONTFIX

--- Comment #11 from Walter Bright <bugzilla at digitalmars.com> ---
The purpose of throwing an Error is to abort the program, but allow the
programmer to catch it and execute some shutdown code.

As mentioned earlier, scope guard will catch Errors, but it should really only
catch Exceptions. This hasn't been fixed because there's existing code that
relies on it catching Errors.

The default behavior of generated code is to throw Errors on things like array
bounds failures. This behavior can now be adjusted with the -checkaction
switch:

https://dlang.org/dmd-windows.html#switch-checkaction

For existing compiled code, onRangeError can be used to set your own handler
for array bounds failures:

https://dlang.org/phobos/core_exception.html#.onRangeError

Similarly, there's onAssertError, etc.

Unittest failures at the top level do not call the assert fail handler, they
call _d_unittestp(), which then calls the assert error handler. This means you
can supply your own _d_unittestp() replacement.

I believe this is sufficient flexibility in the handling of Errors.


> Ignore nothrow in the compiler codegen. Assume errors can always be thrown, even in nothrow (indeed they can).

Do not throw Errors when one expects RAII to unwind the stack. It will not do
so reliably, and is not expected to. Throw Exceptions instead. Catching an
Error does not mean the program is in a reliable state, and is only for the
purpose of trying to catch a falling knife and hoping something of the
program's state can be saved before aborting.


> Replace throwing/catching Errors with a different mechanism to signal/handle errors without incorrect stack unwinding.

I believe the above mechanisms give the programmer that option.


I'm going to mark this as WONTFIX because it's working as designed and there
are mechanisms in place to customize the behavior.

--