View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2012
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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
Re: Exception/Error division in D
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home