Making Errors errors

[Timon Gehr]

On 28.01.21 18:59, Max Haughton wrote:
> It has been discussed in a different thread (Making throwing an error an 
> instant failure, catching Error etc.)
> 
> I am starting to put together a patch to try out this behaviour, what do 
> we actually want it to do - should it call a user specified handler, 

Ideally, yes. The handler should not be allowed to return and it would 
be useful if there was some way to allow stack unwinding in code 
compiled using a special compiler flag. (This requires some support from 
the compiler, basically the backend has to ignore nothrow in such builds.)

> druntime,

I guess that's the same as the first option, just a bit harder to access.

> c etc.?

I don't think the behavior should be hard-coded into the compiler.

> 
> The rationale makes perfect sense (Errors should indicate something has 
> gone wrong, the program is in an invalid state - by definition you 
> cannot recover),

You may be able to recover if the failure is contained in a nonessential 
component. Process separation is sometimes a good way to do that, but it 
may be overkill for some projects.

> but the exact behaviour must be specified.

If the program were truly in an invalid state the behavior would be 
undefined and immediate termination would by definition be impossible to 
ensure. That's not always useful though, there's plenty of circumstances 
where immediately killing the program is not what you want, e.g. if the 
program was recording a sequence of user inputs that will allow you to 
reproduce the error.

I think the immediate elevation of every bug into an issue that 
completely undermines the state of the abstract machine is not right for 
every use case. Those are at different levels of abstraction. Your 
abstract machine state is still okay even if some access fails a bounds 
check and if it happens in a nothrow function, there is no way to resume 
execution after the handler.