On Friday, 15 June 2018 at 08:13:44 UTC, Kagamin wrote:
On Wednesday, 13 June 2018 at 17:08:26 UTC, wjoe wrote:
My question was more like what's the benefit of having thrown
Errors corrupt your program state rendering it useless for
debugging ?
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.
Your objects might have been destructed, or maybe not or maybe
just partially.
The only thing safe to assume is that what you've got is useless.
optimization should work in release mode which implies debugged
code and assumes there are no Errors thrown and you get extra
optimization for nothrow functions. Errors are a cheap way to
print diagnostic, because you need to do it for unhandled
exceptions anyway and it's cross-platform too unlike debugger.
A core dump is created by the OS. In a format that a native
debugger understands.
Also leaf functions don't know anything about environment and
can't do meaningful I/O, e.g. realistically you have standard
output only in console applications and not in other
applications.
Exactly. You may not have a console at all, like eg. in Windows
for the most part, or even Linux if you launch the program from a
toolbar button, and what about headless configurations. What good
is printing to stderr in these cases ?
The only sensible thing to do in case of an unrecoverable Error
is to transfer control back to the OS right away and let it
handle the rest.
A mechanism of Errors thrown like Exceptions is too tempting to
mess around with.
Scott Meyers wrote in one of his books, I forget which, that your
design should be easy to use correctly and hard or impossible to
use incorrectly. This is not true for D Errors.
