Re: Should I use exceptions instead of error codes?
mike3 <mike4ty4@yahoo.com> wrote in news:fd846b87-1e40-482e-8318-
dfcf73b426f7@s12g2000prg.googlegroups.com:
Hi.
(crossposted because the program is in C++ and some C++-related
elements are discussed, hence comp.lang.c++, plus general program
design questions are asked, hence comp.programming.)
I'm making this bignum package in C++. I'm wondering though on how to
handle the errors. Right now most operations routines return error
codes if they fail -- but some routines they use inside them, or
overloaded operators, will throw exceptions on failure. For example,
the C++ standard library routines that get used, for instance to copy
vectors or pieces of vectors of digits. These may throw on failure.
Would it be good to then use a consistent system of error handling
where bignum ops always throw exceptions instead of returning error
codes, instead of having some failures throw exceptions and other
failures release error codes (the exceptions would be coming from the
standard lib. functions for example)? What is the "ideal" plan for a
bignum package, anyway?
The rule of thumb that I use is to ask myself if what I want is stack
unwinding or not. That is, do I expect my immediate caller to be able
to handle this problem, or is it more likely to be handled at a higher
level. If I don't expect my immediate caller to be able to handle it,
then exceptions are the best answer for error handling. If I expect my
immediate caller to be able to fix it, then error codes is the way to
go. Sometimes you end up with a sometimes yes, sometimes no sort of
answer and you then pick your favorite.
Exceptions require a certain amount of overhead to throw, so if you
expect to be having the error a lot, then throwing an exception may not
be your best alternative. Of course, if you expect the error a lot, it
is also usually the case that the immediate caller can handle the
problem and move on, so the first guideline catches that, but it is
still a concern.
HTH,
joe