Re: Exception handling
On 5 Mar, 22:56, "James Kanze" <james.ka...@gmail.com> wrote:
On Mar 5, 3:50 pm, "Rune Allnor" <all...@tele.ntnu.no> wrote:
So you advice against using exceptions as a matter of
semantics?
What do you mean be "a matter of semantics"?
.....
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.
OK, I read this as becuse of the term "exception handling",
people tend to use it only in situations that are somehow
"exceptional." I'm sufficiently naive to view exceptions
as another control structure, which might have a wider
scop of use.
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.)
Well, yes, during this thread I have seen that my original
idea was not very good in all its details. I agree with you
in that something like
bool flag;
if (flag =x->testParameter(i)==false)
{
x->repair(i);
if (flag=x->testParameter(i)==false)
{
throw SomeError(i);
}
}
might be better for the test-fix-test-again problem.
However, the last few post of mine have tried to probe
into the reasoning behind some of the apparently
subjective opinions against exceptions.
Some times I can invoke a handler,
....
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.)
No. Different programs using the same library. I tend to test
ideas in old-school console programs, accepting input via
ASCII parameter files. Once those work, I tend to wrap the
business routines in MEX interfaces to link and run inside
the matlab environment. I keep my options open to enable
to wrap a GUI around my routines, for them to be linked
into other systems where they might be useful. Those are
the heavy-duty applications.
I haven't got quite to the point where I make my own GUIs.
I got a book on Qt3 and started playing with it a mere
weeks before the Qt4 book arrived.
As I said above, it's generally easier and cheaper to convert a
return code into an exception than vice versa.
I agree with that. On the other hand, I can't see why one
would like to convert an exception into a return code,
unless one calls the C++ libary from a C program. I don't
do that, so I don't plan for it.
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.
OK, assume one uses a class as a return code:
class SomeError{// whatever relevant parameters and handlers
};
class data{
SomeError testParameter(int);
};
If one now test the parameters, one gets
SomeError e = x->testParameter(i);
Now one needs an elaborate test to find out
what actually went on. The alternative, using
boolean return codes, as the snippet far above,
is far cleaner what source code is concerned.
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.
Well, the logistics of exceptions, what IDE and debugging is
concerned, is a bit heavy duty. As for the second argument,
that's about coding style, isn't it? Instead of returning
an integer with some non-zero value you have to look up
somewhere, the exception mechanism throws an object of
a class named, say,
TableEntryOutOfOrder
or something like that. A carefully designed class contans
both the indexes of the table entries that caused the error
to be detected, and maybe even the corresponding data values.
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?
The "cleanliness" of the code. See below for an example
of a clean interface to an exception handler which is
oblivious to the exact type of the exception object.
All it needs to know, is a common base class for the
exception objects.
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.
The above is not the only way of dealing with exceptions.
Below is a "simple" command-line program that sets up a
structure where a handler takes a poiter to a virtual
base class as argument, and unwinds what method to
use, based on argument type matching.
While I spent a couple of hours getting this up and
running, it is probably a standard pattern (callbacks?):
/****************************************************************/
#include <iostream.h>
class EbClass; // Exception base class
class E1Class; // Exception type 1 class
class E2Class; // Exception type 2 class
class HandlerClass{
public:
virtual void handleException(EbClass*);
virtual void handleException(E1Class*);
virtual void handleException(E2Class*);
};
class EbClass{
public:
virtual void setHandler(HandlerClass*) = 0;
};
class E1Class : public EbClass {
public:
virtual void setHandler(HandlerClass*);
};
class E2Class : public EbClass {
public:
virtual void setHandler(HandlerClass*);
};
void HandlerClass::handleException(EbClass* e)
{
e->setHandler(this);
}
void HandlerClass::handleException(E1Class* e)
{
cout << "Type 1 handler";
}
void HandlerClass::handleException(E2Class* e)
{
cout << "Type 2 handler";
}
void E1Class::setHandler(HandlerClass* h)
{
cout << "Type 1 exception <--> ";
h->handleException(this);
cout << endl;
}
void E2Class::setHandler(HandlerClass* h)
{
cout << "Type 2 exception <--> ";
h->handleException(this);
cout << endl;
}
int main()
{
HandlerClass h;
E1Class e1;
E2Class e2;
EbClass* E[2];
E[0] = &e1;
E[1] = &e2;
int i;
/*********** Essential loop ********************
Here is the point of the whole excercise:
One calls the exception handler with a pointer
to a vairtual base class as argument. No need to
know exactly what goes on; the user only has to
know that there exists a pertinent handler for
all exceptions.
The below is why it makes sense to do something like
=================================================
try{something;}
catch(EbClass e) // Note virtual base class
{
h.handleException(&e); // No need to know details
// about exceptions.
}
=================================================*/
for (i=0;i<2;i++)
{
h.handleException(E[i]);
}
/**************************************************/
return(0);
}
/****************************************************************/
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.)
I think the "essential loop" above is far more transparent
than both the case-switch alternative and the try-catch-catch...
alternative.
Rune
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]