Re: Descriptive exceptions
* Eugene Gershnik:
Alf P. Steinbach wrote:
* Eugene Gershnik:
With regards to what follows I think I can summarise your arguments
as follows
1. throw/catch process is unreliable and so it is better to log any
problem prior to using it
The throw/catch process isn't unreliable (where on earth did you get
that idea?).
You said it yourself when you wrote "It may happen, for example, that an
exception leads to catastrophic failure (all the more likely when it's
outfitted with a lot of data baggage)." and then explained that
catastrophic
failure is something like division by zero or "executing an invalid machine
code instruction resulting from a corrupted stack".
And I continued: "Or, as may be likely with a lot of baggage data in an
exception object (as you argued for), a std::bad_alloc exception during
stack unwinding.".
In short, anything that causes the program to terminate, hang, or
continue execution in a bad state (producing incorrect results or UB).
Wikipedia, <url: http://en.wikipedia.org/wiki/Catastrophic_failure>,
defines it thusly: "The term catastrophic failure is occasionally used
in computer software to indicate an unexpected error from which the
system cannot meaningfully recover".
Why on earth would
throw/catch lead to these problems more than any other place in your
code is
still beyond me. But to follow your claim it makes throw/catch less
reliable
than say a function call.
No, there is a distinction between tool (reliable, safe) and wielding
the tool in a particular situation (not so reliable, not so safe).
The throw/catch mechanism is by itself reliable: you thought my
positions could be summarized as if it's unreliable, but that's not my
position, nor is it reality.
Signalling failure up to client code, even via function result codes,
can, on the other hand, be dangerous, because the client code isn't
necessarily prepared for tackling failure, and it isn't necessarily of
general high quality. Using exceptions to signal failure makes it at
the same time less and more dangerous. Less, because exceptions cannot
easily be ignored by client code, so there is better chance of thorough
testing causing the client code to deal with calls that fail; more,
because exception propagation through less-than-perfect client code can
cause resource leakage and inconsistent state, which in turn can cause
all sorts of nasty things to happen, including use of stray pointers,
which..., and so on -- do you see how that can result in UB?
The relevance to logging is: if you're going to log, log while you can.
In other words, as early as possible (where you also have the most
detailed information available).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]