On 5/7/25 02:04, Walter Bright wrote:
> 
> Having the program stop when it enters an invalid state is a good thing, not a bad thing.

It seems you have been the one who wants `-release` to be used. While that will cause invalid instruction errors sometimes, it will also disable other checks that would detect an invalid state. This goes as far as disabling bounds checks so memory can get corrupted without the program stopping. x)

On 07/05/2025 12:04 PM, Walter Bright wrote:
> On 5/6/2025 1:53 AM, Richard (Rikki) Andrew Cattermole wrote:
>> This is why its so important to switch over to calling the global functions like assert handler does.
> 
> You cannot know if the global function is corrupted or not at that stage.
> 
> A bad actor can also hijack that global function to facilitate his nefarious schemes.

Which is no different than a signal.

Or our existing assert handler.

>> People can configure it to do whatever they want, we don't have to have a default that is anything but instant crash.
> 
> It's not an instant crash. It generates an invalid instruction fault, which then goes to a handler for it, and the default behavior of that handler is to terminate the process.
> 
> I can tell I'm the oldest person here. I programmed for many years on a machine that had no concept of a fault. When your program crashed, it didn't stop. It kept running. It would execute data as instructions. Invalid opcodes would execute random snippets of microcode. It would run wild. Usually the only way to get control back is to do a cold boot. Now *that* is a crash.
> 
> Having the program stop when it enters an invalid state is a good thing, not a bad thing.
> 
> If you want to keep a program running on your customer's machine after it crashes, that is entirely up to you. But I cannot recommend it.

Right, which is why everything I've said aligns with it defaulting to crashing out with a call to a function.

Even Windows supports logging in process on a crash. In practice this does work every day right now, running on your computer.

On Tuesday, 6 May 2025 at 23:51:05 UTC, Walter Bright wrote:

> 2. if in invalid state, shut down immediately

There's one case where D blatantly violates this principle. Consider a system with allowed state transitions A->B, B->C, C->B, B->A:

```
enum State
{
    A, B, C
}

State state;

void AtoB()
{
    assert(state == State.A);
    state = State.B;
}

void BtoC()
{
    assert(state == State.B);
    state = State.C;
}

void CtoB()
{
    assert(state == State.C);
    throw new Exception("CtoB failed"); // or an Error, doesn't matter
    state = State.B;
}

void BtoA()
{
    assert(state == state.B);
    state = State.A;
}

void main()
{
    AtoB();
    scope(exit)
        BtoA(); // relies on the downstream handler having completed successfully.

    BtoC();
    scope(exit)
        CtoB(); // this handler runs, even though the program is in an invalid state.
}
```

On Wednesday, 7 May 2025 at 07:42:06 UTC, Max Samukha wrote:

>         CtoB(); // this handler runs, even though the program

Misplaced comment. It's the upstream handler (BtoA) that must not run.