On Tuesday, 19 June 2018 at 12:26:15 UTC, Kagamin wrote:
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.
I wrote that 4 days ago. I lost some sleep over that matter and
am long past the idea of trying to correctly clean up in this
situation. You would know that had you read my more recent posts.
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
I'll say it again. The program must have a console(like) device
attached. Otherwise you will not have a stack trace - or at least
it needs to be redirected to a file but that's not very newbie
friendly either because each shell has their own way of doing it
and csh, for example, can't even redirect individually. I'm not
sure about Windows. Even if possible, considering the heavy focus
on GUI, I doubt it's considered best practices there and is a
PITA for sure.
But maybe I missed something else and the only purpose of D is to
make console applications for *NIX like OSs and expect users to
be professional enough to save that stack trace before they close
the terminal ?
And how can you be sure that this bug didn't corrupt memory of
the druntime or anything else related to the stack trace, or even
that it is a single bug ?
And how useful is a stack trace that shows a back trace to the
point of the location the Error was thrown compared to a back
trace to the location of the bug (report)?
and provides a better UX than a core dump (especially to
Please explain. A core dump has everything a printed stack trace
has and more and is as easy as using the debugger itself.
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.
And what guarantee is there that the runtime doesn't crash trying
to print a stack trace ? Could happen just as likely.
