On Monday, 1 April 2013 at 11:33:57 UTC, Lars T. Kyllingstad
wrote:
On Monday, 1 April 2013 at 11:23:50 UTC, monarch_dodra wrote:
On Monday, 1 April 2013 at 11:08:16 UTC, Lars T. Kyllingstad
wrote:
It's time to clean up this mess.
http://wiki.dlang.org/DIP33
A quick comment about your "Error" section. You say:
"In general, Errors should not be caught, primarily because
they indicate that the program logic is compromised, and that
the program may therefore be in an invalid state from which
there is no recovery".
It is actually much worst than that: errors bypass the entire
exception handling mechanism, blasting through code that would
handle destructors, and even flying through functions that are
nothrow. They don't just indicate a "potential" invalid state,
they actually *put* the program in an invalid state, from
which there is no recovery.
That is the main mechanical difference between an "error" and
an "exception", it is not just a philosophical "logic vs
runtime".
I had forgotten about that. Personally, I think that is crazy.
Errors ought to propagate just like Exceptions, they just
shouldn't be a part of your "normal" error-handling mechanism.
I don't know, I find the approach kind of genius personally. If
it is a logic error, and your program is going to die, then why
pay for cleanup? You are getting the radical efficiency of a
normal assert, but with the opportunity to die like with an
exception.
The nicest part (IMO), is that thanks to this, you can assert in
a nothrow function, without violating its nothrow-ness (which we
do all over phobos, and even with built-in arrays).
--------
Under this situation, I'm wondering how the "OutOfMemory" is
dealt with (you don't explain). The only logical explanation I
can see is:
- It is not an exception and is not caught by
"catch(Exception)".
- But it is not an error either, so does not corrupt the
program state.
=> Goal: It is hard to catch, but you *can* recover from it.
Is this correct? Is this what we are going for?
That was the idea, yes.
I like the idea, but it would be particularly breaking change for
nothrow functions though:
void foo() nothrow
{
try
{
throw new OutOfMemory()
}
catch (Exception /+e+/)
{}
}
"Error: foo is nothrow yet may throw"
...what ...? But I caught the Exception!
The bypass would be giving OutOfMemory the same semantics as an
Error, but then, it would just be an actual Error...