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 <s...@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.
