Re: Exception specifications unfortunate, and what about their future?
In article <gg943d$ehq$1@online.de>,
"Thomas Beckmann" <ka6552-360@online.de> wrote:
3. let mywrapper emit any exception, and let the catch point deal with
it.
Depends on the degree of error fixing you can accept. Do you think its
really so uncommon to write stuff like:
int err = MyFunc();
if(err)
return err; // RAII cleans up for us...
My guess is, this kind of error processing is in the vast majority.
But that is the moral equivalent of no exception specifications (don't
know or care about the kind of error; just pass it up the chain). If
more checking is desirable, the code should look more like:
int err = MyFunc();
switch (err)
{
case NoErr:
break;
case ConditionOne:
case ConditionTwo:
//...
case ConditionN:
return err;
default:
unexpected();
}
Yet, since people don't usually write code like this, yours is actually
an argument against exception specifications.
Well checked exceptions would add much value to maintainability.
I'd say less. The problem is all that all the intermediate functions
between the throw and the catch now have to know about all the possible
exceptions just so they can ignore them.
Certainly, you could make the throws() specification of mywrapper() depend
on the template arguments. There some typedefs, traits, etc. could be
provided. I did not think this trough but come up with it in 5min. The
point
is there are ways to solve this.
This has been one of the outstanding issues with exception
specifications for years. If you have new insight on how to solve this,
I'm quite sure many of us would be very interested in hearing about them.
When writing solid code that checks EVERY error condition and every return
code then you get a robust program.
But not every single function needs to have the knowledge about every
possible error condition. For many, it is good enough to know that an
error has occurred and it is time to clean up before passing the error
upstream to something which can handle it. In my coding style, calling
the destructors during stack unwinding to do cleanup no matter how the
function was exited (exception or return) suffices in the vast majority
of cases.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> 773 961-1620
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]