RE: [boost] Re: Proposal: statefull objects

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-29 16:54:47

----- Original Message -----
From: Ed Brey <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 29, 2001 6:00 PM
Subject: Re: [boost] Re: Proposal: statefull objects

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> [No checking in release mode; throw exception in debug mode.]
> > User should use some kind of is initialized. Exception handling is there
in
> > case the user forgets to do that.
> > Anyway, with debug/release modes we are agreed on this.
>
> Throwing an exception in debug mode only doesn't seem to provide much
value.  When debugging, you might as well just halt the program at the
problem, which boils down to simply assert(precondition_is_true).  This
pinpoints the problem source and relieves the user of writing debug-only
catches, as well as other exception-on-precondition-violation pitfalls.
>
> The precondition violation topic has been thoroughly discussed.  For a
summary, see: http://www.boost.org/more/error_handling.html
>
>
I've just read the guidelines above.
Unfortunately, I disagree with the statement (not exactly quoted):
"As a developer, in the case of a precondition violation, I don't want stack
unwinding, I want a core dump".

I want just the oposite, not a core dump but stack unwinding.
The reason is that in an event driven application, an exception inside an
event handler might get caught by the event driver, which can be very
useful, because the fact that the executing task didn't completed don't have
to render the rest of the application unusable. It doesn't matter if the
exception is due to a runtime error or a debug-only precondition violation.
I want the current task to abort, not the entire application.
Usually, I don't have to write any debug only catch clauses. If the piece of
code I am working with -perhaps a windows DLL- is runned by some controller
that can handle failure of my code (and therefore called it inside a try
block) then an exception won't abort the application.

In other words, as a *library* developer, I think that it is a *very bad
idea* to write failure managment code that terminates the running process. A
library should ONLY throw exceptions so that the user of the library can
decide whether a failure in the library must terminate the application (by
just dont calling the library inside a try block) or not.

The abort-on-precondition choice is right for application code, not for
library code.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com