Exception/Error division in D

[Sean Kelly]

On May 24, 2012, at 3:27 AM, Denis Shelomovskij wrote:

> Let's talk about an abstract situation without caring about breaking existing code, current docs, implementation etc.
> 
> Definitions:
> * an Exception is something that tigers scope guards and executes catch/finally blocks if thrown;
> * an Error is something that doesn't do it.
> 
> As a result _we can't do any clean-up if an Error is thrown_ because scope guards and catch/finally blocks aren't executed and the program is in invalid state because of this. Of course it's theoretically possible to code without scope guards and catch/finally blocks but isn't applicably for a real project. E.g. in some editor if and Error is thrown there is no ability to save opened documents.
> 
> 
> Main Question: What do you think can be an Error?
> 
> Can "Integer Divide by Zero" be an Error? Definitely, not.
> 
> Can "Access Violation" be an Error? No, because it's very common to access a field/virtual member function of a null object.
> 
> Can "Out of memory" be an Error? No, because e.g. if I read a user file that require me to create a large array (> 100 MiB, e.g.) I don't want to crash, but just tell, that "Dear user, the file can't be opened because it requires..."
> 
> 
> So what am I think can be an Error? IMHO, nothing. Because throwing everything can indicate that program in very good/terribly bad state and compiler doesn't know anything about that. And because fatal error is fatal the program should just try to print error and close instead of throwing something.

I agree.  However, the benefit to having Error is so that nothrow can exist.  If every exception were considered recoverable then we'd have to throw out nothrow as well, since basically anything can generate an access violation, for example.  Or we could weaken nothrow so that it didn't even allow memory allocations, which would render it largely useless.  For what it's worth, the D runtime does do clean-up for both Errors and Exceptions today.  The only difference is codgen for scope statements and such inside nothrow functions--instead of being rewritten as try/finally the on-exit code is just inserted at the proper scope exit points.


> Let's now return to the real D world. Current implementation treats Errors as Exceptions for now. Documentation keeps silence. All listed "can't be an error" cases are Errors (and it's terrible).
> 
> So why do we has Exception/Error division in D? Because of nothrow. Personally I don't need nothrow for that high cost of making D unusable for me. Lets realize and solve Exception/Error problem and solve nothrow in the second place.

Seems you already know this.  Oops.  I'm inclined to agree, personally.  nothrow is less useful in D than in C++ because it's safe to throw from dtors in D (problems related to throwing from a finalizer during a GC collection aside--that's more an exception safety issue for the GC than anything else).