Exception/Error division in D

[deadalnix]

Le 24/05/2012 12:27, Denis Shelomovskij a écrit :
> 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.
>
>
> 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.
>
>
> Related links:
> http://forum.dlang.org/thread/1566418.J7qGkEti3s@lyonel
> http://d.puremagic.com/issues/show_bug.cgi?id=8135
> http://d.puremagic.com/issues/show_bug.cgi?id=8136
> http://d.puremagic.com/issues/show_bug.cgi?id=8137
>
>
> P.S.
> By the way, the only problem I see in current implementation is a luck
> of "Object finalized" assertion ("True disposable objects (add
> "Finalized!" assertion)" NG thread that didn't interest anybody).
>

The fact that error don't trigger scope and everything is nonsensial.

Today, we know how to implement exception with NO RUNTIME COST when 
exception isn't thrown. No reason not to do it, except executable size. 
As this is a specific constraint, we may want to enable it by a compiler 
switch, but not by default.

I see Error as problem that can occur anywhere in any piece of code.

I think D have some flaw in Exception management. See Segfault vs 
NullPointerException discussions in that very forum. Segfault may be OK 
for some application, but not for a server app that need to be robust.

Error exists because of nothrow. As some exceptions can be thrown 
ANYWHERE, we need a way to separate what is expected to fail, and that 
have to be handled to be nothrow, and what can go wrong anywhere 
(basically, when druntime cannot do its job for some reasons).