Re: Necessity of multi-level error propogation
On Mar 14, 12:18 pm, "Tony" <t...@my.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:b1c57e08-6c26-4bb0-b1a4-1e9326cfd03d@h20g2000yqn.googlegroups.com...
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-
" -- 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."
Sure it does. If you use that pattern, especially if it's the
only one in your toolbox, then your constructors or something
called in those constructors is probably going to have the
possibility of raising an exception.
Apparently, you don't understand RAII. Despite the name, it has
nothing to do with constructors---std::auto_ptr, for example, is
a prime example a RAII, and none of its constructors can fail.
And drop the "only tool in your toolbox" business. You're the
one who's arguing to limit the tools in the toolbox.
"If you can't construct an object (for whatever reasons), that
object shouldn't exist."
"construction" is a subjective term. As I said above, your
need for exceptions to handle errors from constructors depends
on if you define "construction" to be "resource acquisition"
(large potential to raise error) or "data member
initialization" (small/no potential to raise error).
Construction is initializing the object so that it can be used.
There's nothing "subjective" about it. If a constructor returns
without throwing an exception, you have an instance of the
object.
"Throwing an exception from the constructor is the simplest way
to achieve that."
Avoiding the scenario seems much simpler.
Obviously, you've never written any non-trivial code, to make a
statement like that. Avoiding the scenario means expanding the
class invariants, and handling so-called zombie states. It
involves extra code in *every* member function.
"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."
So is a bulldozer, but I won't use one of those to shovel snow
off of my sidewalk, even if I did own one and even if it was
parked in the driveway.
And? How is that relevant to anything?
"It sounds to me that your rejection of them is
more along the "if all you have is a hammer"."
I'm not rejecting them. I'm just developing a better way to
handle errors.
Fine. Show it to us. The more possibilities we have to choose
from, the better it is.
It looks doable at this juncture but I have not encountered
all the scenarios yet. I don't need something as capable or
general as exceptions (yet? Time will tell.).
Now you give the impression that you don't understand
exceptions. Exceptions aren't more "general" or more "capable"
than other methods of reporting errors, per se. They are
different; in some cases, those differences represent an
advantage, and in others, a disadvantage.
--
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