May 30, 2012
Le 24/05/2012 21:33, Sean Kelly a écrit :
> On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
>
>> On Thu, 24 May 2012 06:27:12 -0400, Denis Shelomovskij<verylonglogin.reg@gmail.com>  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.
>>
>> I'll give you a different definition:
>>
>> * an Exception is something that can be handled far away from the context of the error, because the system can safely unwind the stack.
>> * an Error must be handled at the point the error occurred, or the program state is by definition invalid.
>
> This is a good point.  OutOfMemory conditions aside, the only time I'd want to recover from an Error condition was at the point the event occurred, not somewhere up the stack.
>

Often, the point of Exception isn't to recover, but to fail as cleanly as possible. To do so, Error must trigger finally blocks and scope statement.

They probably shouldn't be catchable in @safe code because of the possible invalid state of the program.

But still, often recovering isn't the point when it come to problem as bad as Errors.
May 30, 2012
Le 29/05/2012 18:53, Sean Kelly a écrit :
> On May 24, 2012, at 11:50 PM, Jacob Carlborg wrote:
>
>> On 2012-05-24 21:33, Sean Kelly wrote:
>>
>>> This is a good point.  OutOfMemory conditions aside, the only time I'd want to recover from an Error condition was at the point the event occurred, not somewhere up the stack.
>>
>> You never feel you want to catch at the top level, print a sensible error message and then exit the application? Instead of the application just disappearing for user.
>
> Well sure, but I wouldn't consider this recovery.

As said, recovery isn't the only point of exceptions. For problems as bad as this, you often want to fail cleanly, eventually print an error message or something.

Exception handling discussion are often very focussed on recovery, but the fact is that it is A use case, but not THE use case.

It is very common in real case that you cannot recover from some problems, and just want to fail without messing everything up.
May 30, 2012
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
> The fact that error don't trigger scope and everything is nonsensial.

If an Error is truly unrecoverable (as they're generally supposed to be), then what does it matter? Something fatal occured in your program, so it terminates. Because it's an Error, you can get a stack trace and report something before the program actually terminates, but continuing execution after an Error is considered to be truly _bad_ idea, so in general, why does it matter whether scope statements, finally blocks, or destructors get executed? It's only rarer cases where you're trying to do something like create a unit test framework on top of assert that you would need to catch an Error, and that's questionable enough as it is. In normal program execution, an error is fatal, so cleanup is irrelevant and even potentially dangerous, because your program is already in an invalid state.

- Jonathan M Davis
May 30, 2012
On 30.05.2012 12:33, deadalnix wrote:
> Le 24/05/2012 21:33, Sean Kelly a écrit :
>> On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
>>
>>> On Thu, 24 May 2012 06:27:12 -0400, Denis
>>> Shelomovskij<verylonglogin.reg@gmail.com> 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.
>>>
>>> I'll give you a different definition:
>>>
>>> * an Exception is something that can be handled far away from the
>>> context of the error, because the system can safely unwind the stack.
>>> * an Error must be handled at the point the error occurred, or the
>>> program state is by definition invalid.
>>
>> This is a good point. OutOfMemory conditions aside, the only time I'd
>> want to recover from an Error condition was at the point the event
>> occurred, not somewhere up the stack.
>>
>
> Often, the point of Exception isn't to recover, but to fail as cleanly
> as possible. To do so, Error must trigger finally blocks and scope
> statement.

Yes, finally the voice of wisdom!

>
> They probably shouldn't be catchable in @safe code because of the
> possible invalid state of the program.
>
Interesting point btw.

> But still, often recovering isn't the point when it come to problem as
> bad as Errors.


-- 
Dmitry Olshansky
May 30, 2012
On 30/05/12 10:40, Jonathan M Davis wrote:
> On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
>> The fact that error don't trigger scope and everything is nonsensial.
>
> If an Error is truly unrecoverable (as they're generally supposed to be), then
> what does it matter? Something fatal occured in your program, so it
> terminates. Because it's an Error, you can get a stack trace and report
> something before the program actually terminates, but continuing execution
> after an Error is considered to be truly _bad_ idea, so in general, why does
> it matter whether scope statements, finally blocks, or destructors get
> executed? It's only rarer cases where you're trying to do something like
> create a unit test framework on top of assert that you would need to catch an
> Error, and that's questionable enough as it is. In normal program execution,
> an error is fatal, so cleanup is irrelevant and even potentially dangerous,
> because your program is already in an invalid state.

That's true for things like segfaults, but in the case of an AssertError, there's no reason to believe that cleanup would cause any damage.
In fact, generally, the point of an AssertError is to prevent the program from entering an invalid state.
And it's very valuable to log it properly.
May 30, 2012
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
> On 30/05/12 10:40, Jonathan M Davis wrote:
> > On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
> >> The fact that error don't trigger scope and everything is nonsensial.
> > 
> > If an Error is truly unrecoverable (as they're generally supposed to be), then what does it matter? Something fatal occured in your program, so it terminates. Because it's an Error, you can get a stack trace and report something before the program actually terminates, but continuing execution after an Error is considered to be truly _bad_ idea, so in general, why does it matter whether scope statements, finally blocks, or destructors get executed? It's only rarer cases where you're trying to do something like create a unit test framework on top of assert that you would need to catch an Error, and that's questionable enough as it is. In normal program execution, an error is fatal, so cleanup is irrelevant and even potentially dangerous, because your program is already in an invalid state.
> 
> That's true for things like segfaults, but in the case of an
> AssertError, there's no reason to believe that cleanup would cause any
> damage.
> In fact, generally, the point of an AssertError is to prevent the
> program from entering an invalid state.

An assertion failure really isn't all that different from a segfault. By definition, if an assertion fails, the program is an invalid state, because the whole point of the assertion is to guarantee something about the program's state. Now, if a segfault occurs (particularly if it's caused by something other than a null pointer), the program is likely to be in a _worse_ state, but it's in an invalid state in either case. In neither case does it make any sense to try and recover, and in both cases, there's a definite risk in executing any further code - including cleanup code. Yes, the segfault is probably worse but not necessarily all that much worse. A logic error can be just as insidious to the state of a program as memory corruption, depending on what it is.

> And it's very valuable to log it properly.

Yes, which is why it's better to have an Error thrown rather than a halt instruction be executed. But that doesn't mean that any attempt at cleanup is any more valid.

- Jonathan M Davis
May 30, 2012
On 2012-05-30 12:59, Jonathan M Davis wrote:

> Yes, which is why it's better to have an Error thrown rather than a halt
> instruction be executed. But that doesn't mean that any attempt at cleanup is
> any more valid.

If you're not supposed to be able to catch Errors then what's the difference?

-- 
/Jacob Carlborg
May 30, 2012
On 30.05.2012 17:28, Jacob Carlborg wrote:
> On 2012-05-30 12:59, Jonathan M Davis wrote:
>
>> Yes, which is why it's better to have an Error thrown rather than a halt
>> instruction be executed. But that doesn't mean that any attempt at
>> cleanup is
>> any more valid.
>
> If you're not supposed to be able to catch Errors then what's the
> difference?
>

Having half-flushed/synced database file is no good. I've had pleasure of restoring such things by hand. Trust me, you DON'T want it.

A common technique that can kick start half-flushed binary file is appending certain amount of zeros until it "fits". Depending on structure it may need more then that.

-- 
Dmitry Olshansky
May 30, 2012
Le 30/05/2012 11:32, Don Clugston a écrit :
> On 30/05/12 10:40, Jonathan M Davis wrote:
>> On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
>>> The fact that error don't trigger scope and everything is nonsensial.
>>
>> If an Error is truly unrecoverable (as they're generally supposed to
>> be), then
>> what does it matter? Something fatal occured in your program, so it
>> terminates. Because it's an Error, you can get a stack trace and report
>> something before the program actually terminates, but continuing
>> execution
>> after an Error is considered to be truly _bad_ idea, so in general,
>> why does
>> it matter whether scope statements, finally blocks, or destructors get
>> executed? It's only rarer cases where you're trying to do something like
>> create a unit test framework on top of assert that you would need to
>> catch an
>> Error, and that's questionable enough as it is. In normal program
>> execution,
>> an error is fatal, so cleanup is irrelevant and even potentially
>> dangerous,
>> because your program is already in an invalid state.
>
> That's true for things like segfaults, but in the case of an
> AssertError, there's no reason to believe that cleanup would cause any
> damage.
> In fact, generally, the point of an AssertError is to prevent the
> program from entering an invalid state.
> And it's very valuable to log it properly.

For segfault, it has been proven to be useful in other languages.
May 30, 2012
Le 30/05/2012 12:59, Jonathan M Davis a écrit :
>> And it's very valuable to log it properly.
>
> Yes, which is why it's better to have an Error thrown rather than a halt
> instruction be executed. But that doesn't mean that any attempt at cleanup is
> any more valid.
>

Sorry but that is bullshit. What can be the benefit of not trying to clean things up ?

Do you really consider that corrupted files, client waiting forever at the other end of a connection or any similar stuff is a good thing ? Because that is what you are advocating.

I may sound good on the paper, but in real life, system DOES fail. It isn't a question of if, but a question of when and how often, and what to do about it.