Re: Error codes vs. exceptions
On 29.05.2012 06:15, mike3 wrote:
I've heard about this, and wonder when is it right to use codes, and
when to use exceptions for reporting errors? I've heard various stuff,
such as that exceptions should only be used to indicate "exceptional"
conditions. Yet what does that mean?
Finally it is up to the programmer to take the decision.
But there are some performance aspects as well as some considerations
about exception safe code.
Depending on your language, throwing an exception could be an expensive
task. C++ is yet mostly harmless, but managed languages like Java or
*.NET create an expensive stack trace at the time of the exception
construction or at throw respectively. So it is in general a bad advise
to throw and catch exceptions over and over in loops.
Furthermore exceptions are an unexpected way of changing the execution
flow. While this is intended in most cases there are some pitfalls. Most
code is not fully exception safe. I.e. is shows undefined behavior if
the exception occur at the evaluation of certain (sub-)expressions.
Writing fully exception safe code can be almost as complicated than
writing thread-safe code.
So in fact you should know which of your functions throw exceptions and
which don't. At the end, the advantage of the exceptions, easy code,
might no longer be that large.
I've heard that, e.g. a user
inputting invalid input should not be considered "exceptional", but
something like running out of memory should be.
Well, I dislike general statements like this.
If a wrong user input causes the normal execution flow to be interrupted
at a certain point, a exception might be quite OK. If the execution
continues with the next input box that might be also become red,
exceptions might not hit the nail on the head. You remember, no catch in
a loop (over the controls).
Also, how exactly does one go about determining what is and is not
"exceptional"?
You can't determine this. You have to /define/ this.
What causes your program to abandon normal operation (for a while)?
non-exceptional, but what about something else, like say in a game,
where you have a grid representing a game level, and a request for a
tile of the level is made with a coordinate that is off the map (like
a 64x64 map and something requests a tile at (100, 100).). Would it be
OK for the function working on the tile to throw?
Does this abort normal program flow?
What is the proper action to be taken next?
Or should it give an
"out of range" error code? And as for that mixing: consider, e.g. C++
and probably many other languages: a function has a single definite
return type. Suppose our grid had a function that extracts an
attribute from a cell. What to do when there's an out-of-bounds
request? Throw exception?
Unless your semantics have some default value which could be used to
continue processing, you won't come around to abort the execution flow
here. But it could be a good advice to check this before you call any
function that will not work properly. I.e. you could turn the array
bounds condition into a precondition which could be checked by an assertion.
But what to do? Make every
function return an error code, using pointers to output variables to
store output, and only use exceptions for a rare few kinds of "system-
related" error?
Don't do that. Use exception where they make the code easier to read and
easier to understand. And if you run into performance problems, then
look for a work around. But in C++ this is unlikely as long as you do
not abuse them extensively.
A prominent exception to this rule are APIs that can cross language
boundaries. In this case you mostly have no chance. You need error codes.
Another rule of thumb: if throw and catch are close together with
respect to the call stack it is more likely that an error code fit your
needs. If they are well separated, then exceptions might be preferable.
[...]
Would that be OK or excessive use of exceptions? And if we
are to mix error codes and exceptions, does this mean we should have
the lists of codes and exceptions correspond + a translator to
translate between the two?
Converting an error code into an exception might be a good idea. But the
other way around is most likely not.
And another rule of thumb: the number of exceptions thrown during the
processing of a complete request should be finite. I.e. it must not
scale with the amount of data processed.
Marcel