Comment #0 by dlang-bugzilla — 2014-11-12T21:46:16Z
onFinalizeError will currently catch any Throwable and replace it with a FinalizeError. If the Throwable was an Error, however, this is redundant, and only serves to mask the real source of problems (e.g. an InvalidMemoryOperationError).
Comment #1 by dlang-bugzilla — 2014-11-12T21:50:36Z
Correction: onFinalizeError will chain the caught exception. However, this poses a challenge when finalization was invoked by the GC, and we can't allocate (see issue 13722) - thus, we can't store the chained exception without allocating.
Comment #2 by dlang-bugzilla — 2014-11-13T01:39:49Z
Despite the exception chaining, there is still value in the proposal, in the following scenario:
- A critical memory error (OutOfMemory / InvalidMemoryOperation) occurs somewhere during the execution of a finalizer.
- Because of the nature of the error, the .init is thrown to avoid any allocations.
- Thus, the stack trace is not saved in the exception object.
- The only way to see a stack trace of what caused the exception to be thrown is to stop the program in a debugger at the point where an exception is created.
- On Windows, the Druntime default exception handler is purposefully disabled if the program is running under a debugger.
- Thus, usually, the user only needs to run a D program in a debugger, and it will stop at the first unhandled exception.
- However, this will not work if the exception is caught in order to be chained / rethrown, which is what onFinalizeError does.
Thus, because of the chaining, the call stack which caused InvalidMemoryOperationError to be thrown is irreversibly lost. The user needs to explicitly breakpoint onInvalidMemoryOperation instead (which is currently not possible because of issue 13725).