Re: Exception handling Organization: unknown
Alan McKenney wrote:
On Sep 17, 12:08 pm, Seungbeom Kim <musip...@bawi.org> wrote:
I have heard a lot about:
- comparison between return codes and exceptions
- making the code exception-safe (with RAII, etc)
but not as much about how to actually /use/ exceptions:
e.g. how to design exception classes, and where to install
catch blocks (exception handlers) and what to do in them.
We've tried using exceptions a little, but have ended
up ripping out exceptions in the few places we used them.
The problems I see are:
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. :-)
2. Difficulty insuring that exceptions will be caught.
The problem is that, unless a condition is so
awful that you're better off crashing than continuing
with that condition, you have to make sure that
every possible code path which could lead to a "throw"
contains a "catch".
Unfortunately, C++ doesn't provide any help.
Exception specifications turn out not to be
all that useful, because they're only really
checked at run-time. We don't want our code
to crash when we hit that once-in-a-blue-moon
combination of data that bypasses the "catch",
we want to find out at compile time.
The only way I can see to make sure exceptions are
caught is to set up some sort of code discipline
and do a re-analysis of everthing every time
you make a change. This is just plain impractical
if you have a large code base and a large number
of programmers.
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?
An uncaught exception will surely make a lot of noice during testing.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]