Why is SwitchError an error and how is it unsafe to continue after catching it?

[Jonathan M Davis]

On Sunday, February 24, 2019 5:42:32 AM MST Dennis via Digitalmars-d-learn 
wrote:
> On Sunday, 24 February 2019 at 10:53:09 UTC, aliak wrote:
> > But the following code is very recoverable and I don't see how
>
> > it's unsafe to continue executing:
> There is no guarantee that a final switch throws an Error. From
> what I've heard of Walter [1] (though I can't find it in the
> spec), the default case in a final switch is assumed to be
> unreachable, so in optimized (non-safe release) code you might
> just go out of bounds of the jump table and execute garbage code
> instead of catching and Error, which is only a debug facility.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=13169

IIRC, last time I tested this, with -release, there was no SwitchError when
a final switch was given a bad value, whereas there was without -release.
Regardless, Errors in general are considered fatal conditions and should not
normally be caught. Cleanup code such as destructors, finally blocks, and
scope statements are not necessarily run when an Error (or any kind of
Throwable other than an Exception) is thrown. The program is always in a bad
state after an Error is thrown (it's just a question of how bad), and by
definition, your program is an undefined state if you catch an Error and
attempt to continue. One example of this is that nothrow functions cannot
throw Exceptions, but they can throw all other kinds of Throwables, and the
compiler is not going to put proper exception handling code around a call to
a nothrow function (if it did, that would defeat one of the main purposes of
a function being nothrow). So, while the compiler doesn't guarantee that any
cleanup code is run when an Error is thrown (but it still may happen in some
cases), it definitely won't be run in the case of nothrow functions. So, the
state of the program just becomes that much more invalid as an Error
propagates its way up the stack.

Errors are intended for fatal or unrecoverable conditions such as bad
program logic or running out of memory and as such are really just there to
print the error message and stack trace before killing the program. They are
_not_ intended to be recovered from. So, it is almost never the case that
code should be catching them.

If you have a final switch statement, it's up to you to guarantee that the
variable contains a valid enum value. If it doesn't, you have a bug in your
program that needs to be fixed, regardless of whether a SwitchError is
thrown or whether the program goes and does something wonky, because the
debugging check that results in the SwitchError was not compiled in. Even if
a SwitchError were always thrown on bad input (just like RangeErrors are
always thrown for out-of-bounds array indexing in @safe functions), it would
still be a programming bug that needed to be fixed. Code should not be
trying to catch an Error and continue. Rather, if an Error is thrown, that
means that the code has a bug that needs to be fixed.

- Jonathan M Davis