I suspect Walter mistook the functions for application code, because their purpose is undocumented and they are named "enforce".

On 5/6/25 08:11, Walter Bright wrote:
> D is set up so if you throw an `Exception`, then destructors will run as the stack unwinds. But if you throw an `Error`, you can catch it but the destructors don't run.
> ...

They do.

```d
import std.stdio;

void main(){
    scope(exit) writeln("hi");
    assert(0);
}
```

This still runs even if I mark `main` nothrow. I understand it's not guaranteed (which is bad), but I will take anything I can get.

> The reason is that `Error` means the program has entered an invalid state. Nothing in the program can be trusted any more. The program should do as little as possible to close down gracefully.
> ...

"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!

> The template `std.exception.enforce` works like `assert`, but throws an `Exception` instead.
> 
> The documentation for `enforce()` says:
> 
> $(NOTE `enforce` is used to throw exceptions and is therefore intended to
> aid in error handling. It is $(I not) intended for verifying the logic
> of your program - that is what `assert` is for.)
> ...

Oh I know. I am still going to use `enforce` to verify the logic of my program. Why? Because the language becomes hostile to your program once it can tell anything went wrong. I just want to fix or work around the bug and move on.

> What you can do is override the default assert behavior by inserting your own assert handler by calling `core.exception.assertHandler()`. Be sure to set `-checkaction=D`
> 
> Then you can have assert() behave however you want.

Well, I just don't want any hard crashes in production. Druntime throws other kinds of errors besides assert errors, by the way.

On 5/6/25 09:45, Walter Bright wrote:
> Good that you checked. Go ahead and revert it.

Will do it once I get a large enough patch of spare time.

Though I suspect in some places the reason why you put `assert` is to avoid putting a `new` expression into the code, so not sure what is the best way to go about that.

On 5/6/25 10:03, Walter Bright wrote:
> On 5/5/2025 11:30 PM, Max Samukha wrote:
>> Why would you assume that the code that doesn't rely on the GC is in a working state?
> 
> 
> You're right, there's no guarantee whatsoever that *any* of the code or data is in a valid state.
> 
> But it's much less code, so correspondingly much less likely to have been corrupted.
> 
> I prefer the "Go Directly To Jail, Do Not Pass Go, Do Not Collect $200" method of dealing with crashed programs, hence my preference for executing an invalid instruction. That comes from my experience with avionics in aircraft, where when an invalid state is detected the faulty box is immediately electrically isolated from the rest of the airplane, and the backup is engaged.
> ...

This only works because the plane keeps its own state independent of the electronics.

> But, of course if you want logging, you'll have to risk it.
> 
> I would not enable such logging in any critical software, but it seems I am the only such person.

At some point you'll just have to accept that most use cases are not like this. Then you will maybe also figure out that it is not about what kind of person you are, but about what kind of external factors are relevant to your work. (Hint: I am not currently writing software for avionics.)

And BTW, it appears an ESA mars mission failed partly because an acceleration sensor actively refused to operate for an extended amount of time after acceleration went out of the range it was rated for for a small amount of time. It did so by sticking to one of the ends of the rated range, making the probe compute that it was underground.

This demonstrates that your tools thinking they know better than you how to react to an error condition is also fatal in "critical" applications.

On Tue, May 06, 2025 at 05:48:18PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 5/6/25 08:11, Walter Bright wrote:
[...]
> > The reason is that `Error` means the program has entered an invalid state. Nothing in the program can be trusted any more. The program should do as little as possible to close down gracefully.  ...
> 
> "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."

That's not a very accurate analogy.  A closer analogy to a program trying to fix itself would be a patient self-diagnosing and self-medicating.  "I think I'm hyperventilating because I have type B diabetes.  Let me take these pills and hope for the best."


> I want to diagnose and heal the patient!
[...]

Yes, but the patient can hardly be trusted to diagnose and heal himself. In order for treatment to be reliable, the doctor, so to speak, must be a separate, independent process that hasn't been compromised yet.


T

-- 
Answer: Because it breaks the logical sequence of discussion. / Question: Why is top posting bad?

On 5/6/25 18:29, H. S. Teoh wrote:
> On Tue, May 06, 2025 at 05:48:18PM +0200, Timon Gehr via Digitalmars-d wrote:
>> On 5/6/25 08:11, Walter Bright wrote:
> [...]
>>> The reason is that `Error` means the program has entered an invalid
>>> state. Nothing in the program can be trusted any more. The program
>>> should do as little as possible to close down gracefully.  ...
>>
>> "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."
> 
> That's not a very accurate analogy.  A closer analogy to a program
> trying to fix itself would be a patient self-diagnosing and
> self-medicating.  "I think I'm hyperventilating because I have type B
> diabetes.  Let me take these pills and hope for the best."
> ...

You are wrong. I do not want the program to fix itself. I want the program to subject itself to examination. In the way that I have determined is useful for my particular application.

> 
>> I want to diagnose and heal the patient!
> [...]
> 
> Yes, but the patient can hardly be trusted to diagnose and heal himself.
> In order for treatment to be reliable, the doctor, so to speak, must be
> a separate, independent process that hasn't been compromised yet.
> ...

I am the doctor. The information I have to go on now is "the patient is unwell sometimes".

On Tuesday, 6 May 2025 at 17:02:25 UTC, Timon Gehr wrote:
>>> I want to diagnose and heal the patient!
>> [...]
>
> I am the doctor. The information I have to go on now is "the patient is unwell sometimes".

Except you don't actually want to heal the patient.

You want to shoot that patient in the head after you've figured out how to (shades of Dr. Frankenstein) build a "new improved" worker to ship off to your customer.

(Or more accurately you send the new worker together with a single shot revolver, pick ake and shovel, the customer is supposed to kill and bury the old patient!)

On Tuesday, 6 May 2025 at 06:11:29 UTC, Walter Bright wrote:
> D is set up so if you throw an `Exception`, then destructors will run as the stack unwinds. But if you throw an `Error`, you can catch it but the destructors don't run.

I cannot confirm this:

```
$ cat errors.d
import std;

struct S {
   this (int) { writeln (__PRETTY_FUNCTION__); }
   ~this () { writeln (__PRETTY_FUNCTION__); }
}

int baz ()
{
   auto s = S (2);
   throw new Error ("ex");
   return 0;
}

int main ()
{
   try return baz;
   catch (Throwable t)
      stderr.writeln (t.msg);
   return 1;
}
$ dmd -O errors.d
$ ./errors
S errors.S.this(int __param_0) ref
void errors.S.~this()
ex
```

On 5/6/25 19:39, Derek Fawcus wrote:
> On Tuesday, 6 May 2025 at 17:02:25 UTC, Timon Gehr wrote:
>>>> I want to diagnose and heal the patient!
>>> [...]
>>
>> I am the doctor. The information I have to go on now is "the patient is unwell sometimes".
> 
> Except you don't actually want to heal the patient.
> 
> You want to shoot that patient in the head after you've figured out how to (shades of Dr. Frankenstein) build a "new improved" worker to ship off to your customer.
> 
> (Or more accurately you send the new worker together with a single shot revolver, pick ake and shovel, the customer is supposed to kill and bury the old patient!)
> 

Well, the precise thing that is worth saving and fixing in this instance is the abstract state of the program. It can then often even live on after a code transplant, for the particular application I wrote in this case.

Anyway, at some point any analogy between a person and a program state has to break down, but I think it goes a long way to illustrate that assuming the worst at the first sign of trouble and going berserk to destroy anything of value that might have remained is not appropriate in most circumstances. Why even run a program at that point, the entire stack it runs on is already known to have bugs. x)