RFC: Change what assert does on error
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Fri Jul 4 07:51:00 UTC 2025
On Friday, July 4, 2025 1:24:33 AM Mountain Daylight Time Walter Bright via Digitalmars-d wrote:
> This whole discussion seems pointless anyway. If you want to unwind the
> exception stack every time, use enforce(), not assert(). That's what it's for.
As you know, Exceptions are for reporting problems with user input and/or
the current environment, and they're generally considered recoverable,
because programs should be written to be able to handle such errors
conditions, meaning that they're part of the program's logic.
Errors are for reporting problems with the program itself, and they're not
recoverable, because they prove that program's logic is faulty or that a
condition so severe that the program must be terminated has occurred (e.g.
running out of memory)
However, neither of those conditions necessarily says anything about not
wanting to unwind the stack properly. Yes, if you're going to continue to
run the program after the Exception is thrown, then it's that much more
critical that the stack be unwound properly, but even with Errors, it can be
valuable to have the stack unwind properly, because that very unwinding can
be used to get information about the program as it shuts down.
For instance, Timon does this already with programs that actual users use.
It's just that he has to work around the fact that not all of the clean up
code gets run (some of it does, and some of it doesn't), and the fact that
some of the clean up code is skipped means that he's risking memory safety
issues in the process that wouldn't have been there if the stack had unwound
properly. It also potentially means that he'll miss some of the information
that he's trying to log so that the user can give him that information. And
that information is critical to his ability to fix bugs, because he's not
the one running the program, and he can't get stuff like core dumps from
users (not that you get a proper core dump from an Error anyway).
Skipping some of the stack unwinding code when an Error is thrown makes it
that much riskier for the code that is run while the program is being
shutdown to run. And yes, maybe in some circumstances, that unwinding could
result in files being written from bad program data, but as a general rule,
Errors are thrown because the program was about to do something terrible,
and it was caught, not because something terrible has already happened. And
by not unwinding the stack properly, we increase the risk of things going
wrong as the stack is unwound.
At minimum, it would be desirable if we could configure the runtime (or use
a compiler flag if that's the more appropriate solution) so that programmers
can choose whether they want the stack unwinding to work properly with
Errors or not. That way, it's possible for programmers to get improved
debugging information as the stack is unwound without the stack unwinding
causing memory safety issues. And really, what on earth is even the point of
unwinding the stack at all if we're not going to unwind it properly?
- Jonathan M Davis
More information about the Digitalmars-d
mailing list