RFC: Change what assert does on error

Adam D. Ruppe destructionator at gmail.com
Wed Jul 2 12:37:52 UTC 2025


On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
> Anything can happen in an unknown state, for instance, 
> installing malware. As the threads all share the same memory 
> space, doing something other than aborting the process is 
> highly unsafe.

Since they share access to the same file system, doing anything 
other than igniting the thermite package in the hard drive is 
liable to lead to compromise by that installed malware. And if 
that computer was connected to a network... God help us all, 
we're obligated to press *that* button.

You can never be too safe!

* * *

I keep hearing that asserts and Errors and whatnot only happen 
when the program has encountered a bug, but it is worth nothing 
they tend to happen *just before* a task actually executes the 
problematic condition. Sure, you weren't supposed to even get to 
this point, but you can still reason about the likely extent of 
the mystery and rollback to that point... which is what stack 
unwinding achieves.

Yeah, there's some situations were all is in fact lost and you 
wanna call abort(). Well, you can `import core.stdc.stdlib` and 
call `abort()`! But normally, you can just not catch the 
exception.

This is why OpenD tries to make sure that stack unwinding 
actually works - it will call destructors as it goes up, since 
this is part of rolling back unfinished business and limiting the 
damage. It throws an error prior to null pointer dereferences. It 
gives you a chance log that information since this lets you 
analyze the problem and correct it in a future version of the 
program. Yes, you could (and probably should) use a JIT debugger 
too, operating systems let you gather all this in a snapshot.... 
but sometimes user deployments don't let you do that. (those 
ridiculously minimal containers everybody loves nowadays, my 
nemesis!!!) Gotta meet users where they actually are.

Our story on the threads missing information remains incomplete, 
however. I have some library support in the works but it needs 
integration in the druntime to be really universal and that isn't 
there yet. Soon though!


More information about the Digitalmars-d mailing list