Re: Exception handling
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. The second is very pragmatic: exceptions
are designed to report errors to a location more or less removed
from the point they are detected. In this case, however, you
know up front that the error will be handled immediately in the
calling function. 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? 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).
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, so they don't
vanish.
And there's nothing to prevent returning a more or less
complicated polymorphic class. I do it all the time. (Because
of the copy, you'll probably have to use the letter-envelope
idiom, or just return an std::auto_ptr to the class.)
So, since lots of people advice against this nifty
solution, what fundamental argument against
exceptions is it I have missed?
Just that you're using them where they aren't appropriate. C++
supports any number of mechanisms for reporting errors; three
are generally used in almost every program: abort() (via
assertion failure), exceptions (which are used to abort parts of
the processing, without bringing down the process), and return
codes (which are still used for your everyday "errors", where
you expect the error to be handled immediatly in the calling
routine). In your case, exceptions are appropriate for the
errors which will be propagated back, because they require user
treatment, but not for others. If this decision is made in the
verification function, you could end up with something like:
std::auto_ptr< ReparableError >
error( checkInput() ) ;
while ( error.get() != NULL ) {
log( error->message() ) ;
error->repare( data ) ;
error = checkInput() ;
}
If the decision is to be made in the calling routine:
std::auto_ptr< Error >
error( checkInput() ) ;
while ( error.get() != NULL && isReparable( *error ) ) {
log( error->message() ) ;
error->repare( data ) ;
error = checkInput() ;
}
if ( error.get() != NULL ) {
throw error->raise() ;
}
Even simpler, you could make one of the derived classes signify
no errors, so that the pointer is never null, and write:
std::auto_ptr< Status >
status( checkInput() ) ;
while ( status->state() != Status::ok ) {
log( status ) ;
if ( unrepairable.contains( status->state() ) ) {
throw status->raise() ;
}
data.repair( status ) ;
status = checkInput() ;
}
Any solution using exceptions is going to end up doing the same
thing, but requiring extra variables to control the flow, which
are set in the catch.
--
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! ]