On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote:
D allows various levels of performance and safety. Though I'd
say Errors not working in debug mode is not intended, the
Intention matters not. By definition all program state is
invalid at the point an Error was thrown. From there on it is
impossible to rely on any output, too, because it could be
either correct, corrupted, or completely invalid.
The program is in invalid state when it hits a bug before Error
is thrown, this is seen as a property of a buggy algorithm, Error
is thrown only as a diagnostic of a bug that has happened
already. The state is invalid in a sense that the program
shouldn't continue to serve its intended purpose. Even if Error
was technically correctly unwound, it won't necessarily provide a
correct cleanup when algorithm doesn't expect an exception.
Though in case of D situation may be not as clear as there is
safe code, but we just recently had a nasty memory corruption bug
caused by incorrect trusted code.
A core dump is created by the OS. In a format that a native
debugger understands.
Most of the time a stack trace is enough to diagnose the error
and provides a better UX than a core dump (especially to
newbies). I saw gdb crash trying to make sense of a debugged
program too. Runtime allows to override failure handlers, but
it's not centralized.
