Re: Necessity of multi-level error propogation
On Mar 14, 7:19 am, "Tony" <t...@my.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:b96ff18b-4fcd-4434-a9bf-
"There are really two
cases where exceptions impose themselves:
-- Cases where the error will require abandoning a large block
of processing---in servers, for example, an error which will
require abandonning (and rolling back) the transaction, or
even breaking the connection. In this case, one throw and
one catch may replace literally thousands of if's, as well
as rendering the expression of the algorithms involved
clearer."
I'll keep that in mind when I rearchitect some alpha database
code (it's on my to-do list). It currently doesn't use
exceptions.
It really depends on the application, but I've found them very
effective in transaction oriented systems. In such cases, they
work very well with RAII too: the destructor of the transaction
object does a roll-back if commit hasn't been called. (This
does require some care, however---as a general rule, you
shouldn't do anything which can fail in a destructor. But if
roll-back can fail, you have a problem in maintaining
consistency anyway.)
" -- In constructors, where the alternative is often using zombie
states or some such. If the constructor throws, the object
isn't there, so you don't have to worry about it. Even if
constructors had return codes (and you can easily simulate
them, if you want, using out parameters), exceptions would
be preferable, because they don't leave an incomplete object
laying around."
That may be the side effect of architecting with the RAII
pattern. If instead one chooses to define construction as
initialization rather than resource acquisition (at least in
cases where errors can occur), then the above may not be a
justification for exceptions.
It has nothing to do with RAII. If you can't construct an
object (for whatever reasons), that object shouldn't exist.
Throwing an exception from the constructor is the simplest way
to achieve that.
"There are probably other cases where they have practical
advantages, but these to are absolutes; the alternatives to
exceptions in these cases are very much more expensive, in
terms of development time and maintainability."
I'm hedging that that is not so. It may be one of those "if
all you have is a hammer" things.
It's a tool. It sounds to me that your rejection of them is
more along the "if all you have is a hammer". You have
exceptions, return codes, and a few other alternatives. You
should evaluate each case, and use the most appropriate.
Without excluding any of the alternatives a priori.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34