Exception/Error division in D

[Gor Gyolchanyan]

I'd say, removing nothrow and Error from D would be a good idea. Everybody
throws Exception from anywhere. What would be the practical reason not to
do that (besides potentially breaking code)?

On Thu, May 24, 2012 at 9:51 PM, Sean Kelly <sean at invisibleduck.org> wrote:

> 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).




-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120524/c9f4dd1d/attachment-0001.html>