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

--- Comment #8 from Eyal <eyal@weka.io> ---
(In reply to Mathias LANG from comment #6)
> And that is the real bug, which is reported as 17494

That would be good for predictability.

However, it makes unwinding quite useless, as opposed to a more sensible tls handler installed.

--

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

johanengelen@weka.io changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johanengelen@weka.io

--- Comment #9 from johanengelen@weka.io ---
Spec-wise, https://dlang.org/spec/errors.html#the_d_error_handling_solution
should be changed to clearly state what is happening. Currently, it says that
throwing and catching Error is good for error handling but it very clearly
isn't.
It's contradicting object.exception and object.error page's advice,
https://dlang.org/library/object/exception.html
https://dlang.org/library/object/error.html, of never catching exceptions not
derived from Exception (i.e. Throwables and Errors).

--

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

--- Comment #10 from johanengelen@weka.io ---
Assuming it is intended behavior to not run dtors when an Error is thrown:
 The Error documentation says that "Certain runtime guarantees may fail to hold
when these errors are thrown, making it unsafe to continue execution after
catching them."  But why "after catching" ? What makes catching so special?
User code will still run in (some) dtors. I think what the text is saying is
that "Certain runtime guarantees may fail to hold when these errors are thrown,
making it unsafe to continue execution PERIOD." Perhaps a good solution is to
simply immediately abort execution upon throwing an Error.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

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

--- Comment #11 from Walter Bright <bugzilla@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.

--

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

--- Comment #12 from Eyal <eyal@weka.io> ---
Walter, the question is: what benefits does the current approach have over a much safer approach of having *only* "onError" callbacks that allow the user to write some handling code in case of error before abort?

1) Even if the unwinding behavior is fixed to not unwind in case of errors,
using "catch" blocks to handle errors has very surprising semantics: it runs
code in broken contexts that have not run (scope(exit)s, finally's, destructors
all skipped).

2) Worse still: the program easily continues after catching Errors, even if it is by accident -- in a completely corrupt state.

These would remain 2 huge gotchas to know about when working with try/catch.

Why keep them?

--

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

--- Comment #13 from Jacob Carlborg <doob@me.com> ---
(In reply to Walter Bright from comment #11)

> 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.

Ah, I didn't know about that. Then `_d_unittestp` can be implemented to throw an exception instead of an error.

--