Exception handling
On Sep 21, 7:07 pm, "Bo Persson" <b...@gmb.dk> wrote:
Alan McKenney wrote:
1. Expense. You can't use exceptions unless you can be
quite sure that they will occur rarely. I work with
real-time data, so if too many exceptions are thrown,
we lose data.
Exceptions are supposed to be used for exceptional conditions. :-)
Which means what, exactly?
At least "they will occur rarely" _means_ something.
The catch (if you'll excuse the expression) is determining
at development time how rare any particular condition is.
At that point, using error codes seems a lot more
practical.
And what language support do you have for making sure that all return
codes are properly checked and handled?
Well, if someone adds an error parameter to a function
signature, the compiler will tell you pretty quick if you
don't add it to every call.
At that point, it's a matter of "grep"ing for each call
and then looking at the code. It's a pain, but at least
the complexity is linear in the size of the code, instead
of (potentially) factorial.
If C++ required exception specifications and required that
each function included in its exception spec. every
uncaught exception specified by every function it calls,
it could be checked at compile time. I don't know if this
would be practical, though.
An uncaught exception will surely make a lot of noice during testing.
Assuming that, during testing, you manage to find that
execution path that hits the "throw" without passing a "catch".
If it first happens when you're in Production, you will
suddenly find yourself having to explain to top execs
why a crash was better in this case than simply ignoring the
error.
- - -
Based on what I've read so far in the C++ literature,
I'd say that the idea of exception safety is a fairly
mature concept, but that our understanding of when to use
exceptions is still fairly immature.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]