[dmd-internals] Throwing Errors

[Walter Bright]

On 3/15/2012 2:39 PM, Jonathan M Davis wrote:
> On Thursday, March 15, 2012 14:22:49 Walter Bright wrote:
>> On 3/15/2012 9:29 AM, Sean Kelly wrote:
>>> Is the program really corrupted though?
>> You cannot know that.
>>
>> I really think that going down the path of thinking one can recover from
>> programming bugs is the route to disaster. It goes against everything I know
>> about how to make safe, reliable systems.
> There's a difference between saying that Errors are not recoverable and making
> it so that cleanup code runs when Errors are thrown. Catching an Error and
> continuing the execution of your program is almost never a good idea, but
> catching it, doing some cleanup and rethrowing it (as finally, scope(failure),
> and scope(exit) would do) is a different matter. No, it may not work, but it
> can also allow you to do things that need to be done at cleanup. And _not_
> running scope statements, destructors, and finally blocks makes catching Errors
> even _less_ safe even when it _does_ make sense. And upon occasion, catching
> Errors _does_ make sense even for cases other than cleanup.

I don't agree. The more code you run after a program bug, the more likely you 
aren't going to be able to run your shutdown/logging code.

If any of that cleanup code actually needs to run on program bug shutdown, it 
still can be done with catch/throw. The other stuff assumes normal operation and 
is not needed to be run for shutdown/logging.

> There is a difference between recovering from an Error and a recovering from a
> programming bug. Not all Errors necessarily indicate that there's a bug in the
> program. They just indicate that they've hit what is almost certainly a fatal
> condition. For instance, OutOfMemoryError is generally fatal, but it doesn't
> necessarily indicate a bug in the program. If caught close to the throw point,
> it might be possible to recover in some cases. It's just that the current
> state _is_ fatal unless you can do something to fix it. In most cases you
> can't, but in a few, rare ones, you can.

The whole point of Errors is that they are non-recoverable. Yes, we did make a 
decision that out of memory is a non-recoverable error. If someone wants to 
recover from it, they should use malloc or some other API, not the GC.


> So no, trying to recover from programming bugs is a _not_ a good idea, but
> there _are_ rare cases where catching Errors makes sense, and making it so
> that they skip scope statements, destructors, and finally blocks makes them
> even _less_ safe to catch and makes it so that you often can't recover from an
> Error even in the rare cases where you should be able to.

If people want to recover from Errors, they should be using Exceptions instead. 
D should not be wishy washy about this.

> The main question that I see is whether trying to run cleanup code when an
> Error is thrown is likely to make things worse or not. If that's a really high
> risk, then it may be better to have scope statements, finally blocks, and
> destructors skipped. But if it's at all debatable as to whether it's better or
> worse to run cleanup code when an Error is thrown, then I'd argue that code
> will be _less_ buggy if they're run when an Error is thrown. That doesn't make
> it so that the programmer should be catching Errors much, but it _does_ make
> it so that it's reasonably safe in the few cases where it _does_ make sense to
> catch them.
>

I've been arguing with engineers for 25 years who insist that they should be 
able to recover from detected programming bugs. It's wrong, wrong, wrong, wrong.

If you want to recover, use an Exception.