Stephan Bergmann wrote:

> Mathias Bauer wrote:
>> Stephan Bergmann wrote:
>> 
>>> One abstraction level higher, throwing an exception upon detecting say a 
>>> broken invariant is in general useful only if you very carefully 
>>> designed your program so that you can catch the exception somewhere 
>>> where you can go from the broken state of your program to a good state 
>>> (and where you can inform the client that some operation failed, if the 
>>> good state is not a state expected by the client).
>> 
>> While this might be theoretically correct my practical experience of at
>> least 8 years of successful crash recovery says that it works for the
>> vast majority of crashes and I won't accept that we drop it in any
>> situation just because there is no theoretical proof that it works all
>> the time.
> 
> You confuse me here.  With "crash recovery" I assume you mean the 
> activities triggered from within the signal handler.  My paragraph that 
> you quote is about whether to throw an exception or to abort upon 
> detecting some illegal state.  I do not see the connection.

My perception was that aborting is an immediate program exit and so
circumvents the crash reporting and recovery. And that is something I
wouldn't do ever. At least we should always try.

> Re your comments about crash recovery:  I never claimed that there are 
> no cases where what we do from within the signal handler happens to work 
> as expected (I used the word "reliably" in what you did not quote), and 
> I never requested to "drop it."

See my explanation above.

>> I would see it the other way around: only if you have a case where you
>> know for sure that crash recovery is of no avail you can abort
>> immediately (but then you will also lose the crash report).
> 
> ???  abort() -> raise(SIGABRT) -> signal handler

Sorry for misunderstanding "abort", my perception as explained above was
obviously wrong.

Ciao,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to