Re: Exception handling
On Mar 5, 3:50 pm, "Rune Allnor" <all...@tele.ntnu.no> wrote:
On 5 Mar, 11:36, "James Kanze" <james.ka...@gmail.com> wrote:
On Mar 4, 7:49 pm, "Rune Allnor" <all...@tele.ntnu.no> wrote:
On 4 Mar, 13:25, "James Kanze" <james.ka...@gmail.com> wrote:
Rune Allnor wrote:
How should one implement this recursive try-catch structure?
To begin with, it sounds to me like exceptions are the wrong
solution here.
Some of the other respnders have indicated similar views.
Could somebody please elaborate on why?
Two reasons, really. The first is somewhat philosophical, but
you're checking user input; there's nothing exceptional about
errors in user input.
So you advice against using exceptions as a matter of
semantics?
What do you mean be "a matter of semantics"? The point of
exceptions is to propagate the error up the stack. If the
semantics are such that you probably won't want to propagate the
error beyond the calling function, exceptions aren't indicated.
If you base your semantics on the name, exceptions are for
exceptional cases.
Maybe I'm reading too much into the argument,
but it seems to me that you mean that an "exception"
ought to be used to flag "exceptional" events?
That's the original motivation behind the name.
The second is very pragmatic: exceptions
are designed to report errors to a location more or less removed
from the point they are detected.
Which is why the mechanism is so powerful.
In this case, however, you
know up front that the error will be handled immediately in the
calling function.
No, I don't *know*. An immediate fix is one of several
possibilities, but by no means a certain event.
But your problem was an immediate fix. IMHO, when in doubt, use
a return code; it's easier and cheaper to map a return code into
an exception than vice versa. (Still another solution would be
a callback, something along the lines of the visitor pattern.
The loop is in the verification routine; each time it finds an
error, it calls the visitor; if the visitor can fix it, it does,
and returns, if not, it throws the exception.)
Some times I can invoke a handler, say, if the input is
provided via a GUI. If an error is detected, a window
pops up to alert the user of the problem, and ask him
to provide valid input.
At other times, I might test for small numbers in
a sequence that ought to be strictly ascending.
I might raise an exception to warn of "small"
intervals, and check some user settings database
to see if the user has sanctioned the use of very
small intervals.
At still other times, like in batch jobs, the
best option might be to just bail out.
Different visitors, chosen by some configuration option? (In a
batch job, you typically want to try and continue, at least as
long as there is a possibility of finding more errors.)
That's not what exceptions are for, and as
you have noticed, they are more awkward to handled.
You expect to handle the error in the calling
function, so a return code would be generally more indicated.
Then, you just write a classical loop.
Nope, I don't want to do that. I used to do that sort of
things in C, and the programs quicly grew ugly. Switch
statements all over the place, testing the error codes
to find out exactly what had gone wrong. Parameter lists
on function calls growing out of proportion to keep
track of where things went wrong.
I'm not sure I understand. Do you want to process the error or
not?
Yes, but I like to keep my options open. See above.
As I said above, it's generally easier and cheaper to convert a
return code into an exception than vice versa.
Generally, the "ugliness" exceptions avoid is in the
functions which don't process the error, but just transmit it.
At the point where you actually process the error, exceptions
are even uglier than return codes (although it depends on what
you do in the processing---if you end up aborting the treatment,
there's no problem).
Why? The exceptions I have tested provides their own
error messages and contain all relevant parameters.
So do the return codes, or...
Staying with the sequence of ascending numbers, it is
no problem whatsoever to throw the indexes of the
troublesome numbers as well as the numbers themselves,
in an exception class that is only thrown for that
type of error.
I can't see what makes that "ugly"?
The same thing that makes handling return codes ugly: you've got
extra code in the function which has nothing to do with it's
normal processing. The difference between exceptions and return
codes is 1) with exceptions, you don't have the extra code in
the functions which just propagate the error, without processing
it, and 2) it's generally clearer what's going on (why you got
there, etc.) when you enter the actual error handling via an if,
rather than an exception. When you propagate through several
levels, the first consideration largely outweighs the second.
When you don't, however, the first consideration is irrelevant.
With these exceptions I am testing, I have a nifty base
class which contains some virtual methods to display an
error message and an integer to hold an index. The
various error condion exceptions are derived from this
class, with error message overloads. When I throw the
exception, the index of the entry where the error was
detected is saved in the exception class. Even more
convenient, I only have to call
e->printErrorMessage();
to find out exactly what the error is. All those tests
and conditionals have vanished. Very convenient.
Except that you apparently need the conditionals to decide
whether to repair, abandon treatment or process,
Those decisions are based on other conditionals than those
regarding error reporting. All the relevant information
about the error -- type, location, offending data -- is
trivially contained in an instance of the exception class.
Or the return code class. What's the difference?
so they don't vanish.
I'll agree with you in that each error has to be handled
on its own terms. Using exception classes, one does not
only simplify the reporting and tracking of the error.
By exploiting the type-checking mechanism, one can use
generic method calls to, say, error handlers in GUI
systems. That way, all the switch statements suddenly
disappear from the code. Which certainly suits me.
What's the difference between a switch and :
try {
// ...
} catch ( A ) {
// ...
} catch ( B ) {
// ...
} ...
As soon as control flow is involved, exceptions are obfuscation.
Except, of course, when the only control flow is abandoning the
function in progress. Exceptions optimize (for the programmer,
not runtime) handling the particular case of abandoning the
function (or the functions) in progress, at the cost of making
the other control flows less transparent. (Most of the times I
use exceptions, the control flow involved in handling the error
is pretty trivial, so the exception doesn't make it
significantlyl less transparent either.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]