What is the point of nothrow?

[wjoe]

On Tuesday, 12 June 2018 at 18:41:07 UTC, Jonathan M Davis wrote:
> On Tuesday, June 12, 2018 17:38:07 wjoe via Digitalmars-d-learn 
> wrote:
>> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis 
>> wrote:
>> > On Sunday, June 10, 2018 23:59:17 Bauss via 
>> > Digitalmars-d-learn
>> > wrote:
>> > Errors are supposed to kill the program, not get caught. As
>> > such, why does it matter if it can throw an Error?
>> >
>> > Now, personally, I'm increasingly of the opinion that the 
>> > fact that we have Errors is kind of dumb given that if it's 
>> > going to kill the program, and it's not safe to do clean-up 
>> > at that point, because the program is in an invalid state, 
>> > then why not just print the message and stack trace right 
>> > there and then kill the program instead of throwing 
>> > anything? But unforntunately, that's not what happens, which 
>> > does put things in the weird state where code can catch an 
>> > Error even though it shouldn't be doing that.
>>
>> Sorry for off topic but this means that I should revoke a 
>> private key every time a server crashes because it's not 
>> possible to erase secrets from RAM ?
>
> The fact that an Error was thrown means that either the program 
> ran out of a resource that it requires to do it's job and 
> assumes is available such that it can't continue without it 
> (e.g. failed memory allocation) and/or that the program logic 
> is faulty. At that point, the program is in an invalid state, 
> and by definition can't be trusted to do the right thing. Once

If memory serves a failure to malloc in C can easily be checked 
for success by comparing the returned pointer to null prior to 
accessing it. If the pointer is null this only means that memory 
allocation for the requested size failed. I fail to see how this 
attempt at malloc could have corrupted the entire program state 
invalid.
Why would it be inherently unsafe to free memory and try to 
malloc again.
But maybe it's an optional feature and could just be disabled.
But maybe it does mean that the program cannot continue.
I still don't see a need to force quit without the opportunity to 
decide whether it's an error to abort or an error that can be 
fixed during run time.

> the program is in an invalid state, running destructors, scope 
> statements, etc. could actually make things much worse. They 
> could easily be operating on invalid data and do entirely the 
> wrong thing. Yes, there are cases where someone could look at

could. Like erasing the hard drive ? But that could have happened 
already. Could be the reason of the error, in the first place. 
Destructors, scope statements etc. could also still work 
flawlessly and it could become worse because of not exiting 
gracefully. Data not synced to disk, rollback not executed, vital 
shutdown commands omitted.

> what's happening and determine that based on what exactly went 
> wrong, some amount of clean-up is safe, but without knowing 
> exactly what went wrong and why, that's not possible.
>

But Errors have names, or codes. So it should be possible to 
figure out what or why. No?
In case of an out of memory error, maybe the error could be 
resolved by running the GC and retry.

I'm afraid I really can't grasp the idea why it's the end of the 
world because an Error was thrown.

> And remember that regardless of what happens with Errors, other 
> things can kill your program (e.g. segfaults), so if you want a 
> robust server application, you have to deal with crashes 
> regardless. You can't rely on your program always exiting 
> cleanly or doing any proper clean-up, much as you want it to 
> exit cleanly normally. Either way, if your program is crashing

it is possible to install a signal handler for almost every 
signal on POSIX, including segfault. The only signal you can't 
catch is signal 9 - sigkill if memory serves.
So I could for instance install a clean up handler on a segfault 
via memset, or a for loop, and then terminate.

If program state, and not necessarily just my own programs but 
any programs that store secrets in RAM, is to be considered 
invalid on a thrown Error, and I cannot rely on proper clean up, 
I must consider a secret leaked as soon as it is stored in RAM at 
the same time an Error is thrown.

Therefore the only conclusion is that such a language is not safe 
to use for applications that handle sensitive information, such 
as encrypted email, digital signing, secure IM or anything that 
requires secrets to perform it's work.
This is really sad because I want to think that improved 
technology is actually better than it's precursors.
What I would hope for is a mechanism to help the developer to 
safely handle these error conditions, or at least gracefully 
terminate. Now I understand that nothing can be done about 
program state actually messed up beyond repair and the program 
terminated by the OS but just assuming all is FUBAR because of 
throw Error is cheap.

> frequently enough that the lack of clean-up poses a real 
> problem, then you have serious problems anyway. Certainly, if 
> you're getting enough crashes that having to do something 
> annoying like revoke a private key is happening anything but 
> rarely, then you have far worse problems than having to revoke 
> a private key or whatever else you might have to do because the 
> program didn't shut down cleanly.
>
> - Jonathan M Davis

I can't know if the error was caused by accident or on purpose.
And I don't see how frequency of failure changes anything about 
the fact. If a secret is left in RAM it can be read or become 
included in a coredump. Whether it leaked the first time or not, 
or not at all I wouldn't know but a defensive approach would be 
to assume the worst case the first time.
Also it doesn't just relate to secrets not being cleaned up, but 
I could imagine something like sending out a udp packet or a 
signal on a pin or something alike to have external hardware stop 
its operation. Emergency stop comes to mind.

Further, does it mean that a unitest should run each test case in 
it's own process? Because an assert(false) for a not yet 
implemented test case would render all further test cases 
(theoretically) undefined, which would make the unitest{} blocks 
rather useless ,too?

Sorry for off topic...