Exception slipping through the catch block?

[Jonathan M Davis]

On Thursday, November 8, 2018 10:55:45 AM MST Stanislav Blinov via 
Digitalmars-d-learn wrote:
> On Thursday, 8 November 2018 at 16:13:55 UTC, Mike Parker wrote:
> > On Thursday, 8 November 2018 at 15:50:38 UTC, helxi wrote:
> >> Although it's pretty frustrating, isn't it? Now not only I
> >> have to think about catching exceptions but also about Errors,
> >> and have no guarantee that I have everything under control.
> >
> > No, you should never catch Errors. They're separate for a
> > reason.
>
> Never say never :) There are legitimate cases for catching an
> Error or even a Throwable (for example, error propagation in a
> multi-threaded environment). However, this is not one of such
> cases.

Yeah, but basically, the rule of thumb is never. Errors are fatal error
conditions which are supposed to terminate the program, and programs should
not be trying to recover from them. No one should be attempting to catch
them unless they know what they're doing, which honestly, probably isn't
going to be very many people for something like this.

Exceptions are for error conditions which are potentially recoverable.
Program input or environmental state was bad (e.g. a missing file). They
aren't necessarily indicative of bugs in the program, and the program can
potentially recover from them and continue to function perfectly fine.

Errors on the other hand, are used to indicate actual bugs in the program or
fatal conditions with resources which cannot be recovered from (e.g. the GC
running out of memory). They are intended simply to be informative and not
to be caught. The stack is not necessarily properly unwound when they are
thrown. Full exception handling code is not necessarily even in place when
they are thrown, and they can be thrown from nothrow code. By definition,
your program is in an invalid state when you catch an Error, and catching an
Error to do much of anything is dangerous.

> helxi, an AssertError means there's a problem with your code, it
> needs to be dealt with by fixing the code, not swallowing the
> Error.

Specifically, AssertError means that either an assertion failed or something
simulating an assertion failed (such as std.exception.assertThrown), so it's
something in the code that quite specifically indicates that there's a bug
in the code and that a condition that must be true for the code to be in a
valid state was false. So, whatever it reported should be tracked down and
fixed. In this particular case, it looks like a piece of code called
dropBackOne on an empty range.

- Jonathan M Davis