Exception/Error division in D

[Jonathan M Davis]

On Thursday, May 31, 2012 08:26:18 Jacob Carlborg wrote:
> On 2012-05-30 23:16, Jonathan M Davis wrote:
> > You can catch them to print out additional information or whatever is
> > useful to generate more information about the Error. In fact, just what
> > the Error gives you is already more useful: message, file, line number,
> > stack trace, etc. That alone makes an Error more useful than a halt
> > instruction.
> 
> If I recall correctly you has been arguing that Errors shouldn't be
> catchable, as they are today, and this needed to be fixed. Hmm, or was
> that Steven.

No. I haven't been arguing that. It's not particularly safe to catch Errors, 
but they're catchable on purpose. It's catching and _handling_ an Error that's 
generally a bad idea - that and continuing to execute after catching the Error 
rather than letting the program terminate. It may be appropriate in very rare 
examples where the programmer knows what they're doing, but in general, 
catching them to do much beyond print out additional information or maybe do 
some absolutely critical cleanup is a bad idea.

The real question is whether any cleanup should be attempted on Error (i.e. 
destructors, scope statements, and finally blocks). Running that code is risky 
when an Error occurs, because the program is in an invalid state. It's 
possible that running it could actually do damage of some variety, depending 
on the state of the program and what the cleanup does. But skipping all of 
that cleanup can be a problem too, since that cleanup generally needs to be 
done. Depending on what the Error was, the cleanup may actually work and 
therefore leave the program in a less invalid state. So, it's a question of 
whether attempting cleanup in an invalid state or skipping cleanup in an 
invalid state is riskier. Per Walter, there's no guarantee that that cleanup 
will occur, but with the current implementation it almost always does.

> > You can catch them to attempt explicit cleanup that absolutely must be
> > done
> > for whatever reason (with the knowledge that it's potentially dangerous to
> > do that cleanup due to the Error).
> > 
> > You can catch them in very controlled circumstances where you know that
> > continuing is safe (obviously this isn't the sort of thing that you do in
> > @safe code). For instance, in some restricted cases, that could be done
> > with an OutOfMemoryError. But when you do that sort of thing you have to
> > catch the Error _very_ close to the throw point and be sure that there's
> > no cleanup code in between. It only works when you can guarantee yourself
> > that the program state is not being compromised by the Error, and you're
> > able to guarantee that continuing from the catch point is safe. That
> > works in some cases with AssertError in unit test code but becomes
> > problematic as such code becomes more complex.
> 
> I'm mostly interested in letting the user know something went wrong and
> then exit the application.

That would be the most typical use case for catching an Error and certainly is 
the least risky of the reasons that you might do it.

- Jonathan M Davis