Making Errors errors

[Max Haughton]

On Thursday, 28 January 2021 at 18:33:17 UTC, Adam D. Ruppe wrote:
> On Thursday, 28 January 2021 at 17:59:41 UTC, Max Haughton 
> wrote:
>> 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, druntime, c etc.?
>
> Here's a crazy idea: when this switch is in place, it just 
> never actually honors your catch handlers.
>
> so then throw Error is the same as an uncaught exception and 
> thus trigger the debugger at the throw site instantly.
>
>> (Errors should indicate something has gone wrong, the
>> program is in an invalid state)
>
> In real life Errors are rarely this extreme. Most of them 
> indicate that the program *would* get into an invalid state if 
> it proceeded, but since it stopped before actually executing 
> it, things are still fine.

Not a bad idea. I think I'll try that first.

And that may well be true but when I use A
assert, for example, I often think of it in the same context as 
one would in formal verification i.e if this is wrong something 
catastrophic has happened. If the problem is exceptional but 
ultimately recoverable use Exceptions.

I also feel that, potentially against the grain of Phobos, 
parsers should not throw - e.g. std.conv probably fails more than 
it succeeds in many code bases.