[OT] OT: Null checks.

[Timon Gehr]

On 5/7/25 01:51, Walter Bright wrote:
> On 5/6/2025 8:48 AM, Timon Gehr wrote:
>> "The patient has a light cough. The patient has thereby entered an 
>> invalid state. The doctors must now do as little as possible before 
>> they blow up the hospital in order to euthanize the patient and 
>> everyone else that may have been in contact with them."
>>
>> I want to diagnose and heal the patient!
> 
> When the autopilot has entered an invalid state for unknown reasons, you 
> really don't want it to continue to run. Violent maneuvers can rip the 
> airframe apart.
> 
> If a hospital blows up because the computer failed, that's a terrible 
> design.

Thanks for agreeing with this at least. It however seems you did not get 
the point. This was an analogy. The terrible design here is 
hard-crashing "debug-release" builds with the attitude that it is all 
the same anyway.

> The correct design for a critical system is:
> 
> 1. detect invalid state
> 2. if in invalid state, shut down immediately and engage the backup
> ...


Sure, just let me do these things in the way that is appropriate.

I do not have a backup here though. It's not typically viable to have a 
separate entity code exactly the same application (hopefully with 
different bugs), while having both of them share all of the important 
internal state right to the point where one of them decides to go out 
the window.

> 
>> Well, I just don't want any hard crashes in production. Druntime 
>> throws other kinds of errors besides assert errors, by the way.
> 
> Replace the `-release` switch in the build of druntime with `-release - 
> checkaction=D`.
> ...

This does not work.

> I do understand you need to debug remotely, and presumably your program 
> is not critical to your customer.

The main thing that suffers here is my established reputation of fixing 
any observed issues within 24 hours. Your attitude seems to be if you 
want to maintain such a reputation, either don't use D, or have the 
foresight to customize your setup to the point where you are effectively 
maintaining your own fork before you even start using the language.

> Doing a custom rebuild of druntime 
> with `-release -checkaction=D` is entirely appropriate for your 
> situation.

The problem with this is that you don't know you are in this situation 
until there was at least one unexplained crash, and it complicates build 
instructions for third parties, as well as the setup of new build machines.

> But I'm hesitant about making it the default build.

I think this would be the wrong call. I guess another valid option is to 
just ship both builds, so that hobbyists can still enjoy crashing into 
the wall at 1001mph instead of 1000mph.