RFC: Change what assert does on error

[Walter Bright]

On 7/2/2025 5:37 AM, Adam D. Ruppe wrote:
> I keep hearing that asserts and Errors and whatnot only happen when the program 
> has encountered a bug,

Using asserts for anything other than detecting a programming bug in the code is 
using the wrong tool. Asserts are not recoverable.


> 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

If a variable has an out of bounds value in it, it cannot be determined why it 
is out of bounds. It may very well be out of bounds because of memory corruption 
elsewhere due to some other bug or a malware attack.


> and rollback to that point... which is what stack unwinding achieves.

Stack unwinding may be just what the malware needs to install itself. The stack 
may be corrupt, which is why Error does not guarantee running destructors on the 
stack.


> 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.

Limiting the damage from a program being in an unknown and corrupted state is 
only achieved by limiting the code being executed to possibly logging the error 
and exiting the program. Nothing else.

`enforce` https://dlang.org/phobos/std_exception.html#enforce is a soft assert 
for errors that are recoverable.