Re: efficient exception handling
* James Kanze:
On Oct 15, 9:44 am, terminator <farid.mehr...@gmail.com> wrote:
I found the following as the ANSI C++ std behavior of the
exception handling mechanism in the documentation of my
compiler:
[...]
I do not feel much doubt about the standardness of the above
context , but IMO the std could be more elegant with the some
minor modifications;
i.It looks as if the stack unwinding is performed at 'throw'
site .but IMHO if the stack unwinding is left to the 'catch' site the
program will be more flexible;because it gives us the option to handle
the trouble and resume the program from the statement after the
throw, rather than stopping what was performing before the
throw.
This option was discussed by the committee when exceptions were
added to the language, and rejected. Basically, the people with
actual experience with it (in other languages) reported that it
couldn't really be used effectively, and it complicated the
implementation somewhat, so the decision was made to not support
it. (Simply specifying the semantics for this would be
extremely complicated. The catch block runs in a different
scope than that where the exception was raised.)
Therefore a default exception handler also need be implicitly
defined ,so that it can catch all exeptions and do nothing but
unwind the stack and terminate.
IMHO, the current situation is actually better. A compiler is
free to terminate without unwinding the stack (and
some---including the ones I use---do), so you can see where the
uncaught exception came from.
Well, there is in interesting middle way, the Eiffel retry. Basically
it's built on the notion that a function (or block, whatever) either
succeeds or fails, where failure is the propagation of an exception. So
you set up a loop, and in catching an exception you can either loop
again (presumably correcting something or just retrying after a delay),
or propagate the exception, e.g. by rethrowing or throwing some new x.
I once suggested implementing the Eiffel scheme by allowing "goto try"
in a catch block, which would then require a "throw;" as the last
statement of that catch block.
However, this can be simulated via the template pattern in C++, e.g.
Dave Harris' suggestion (as I recall in response to the "goto try")
struct Retrier {
void doit( unsigned maxTries );
protected:
virtual void attempt( unsigned tryCount,
const std::string &errorMessage ) = 0;
};
void Retrier::doit( unsigned maxTries ) {
std::string errorMessage;
for (unsigned tryCount = 1; true; ++tryCount)
try {
attempt( tryCount, errorMessage );
return;
}
catch (std::exception &e) {
if (count < maxTries)
errorMessage = e.what();
else
throw;
}
}
}
but that's kludgy and not as generic as one would wish: it's like the
language lacked blocks so that you had to define a function everywhere
you needed a local block (essentially the same problem as with e.g.
for_each, and perhaps C++0x will help in this respect).
And in response to the above idea I later suggested syntax like
succeed_or_throw_block:
succeed_or_throw_clause +
(fallback_clauses | nothing) +
(cleanup_clause | nothing)
succeed_or_throw_clause:
"succeed_or_throw" compound_stmt
fallback_clauses:
fallback_clause | fallback_clauses fallback_clause
fallback_clause:
"fallback_to" (xinfo_object_decl | nothing) compound_stmt
cleanup_clause:
"clean_up" compound_stmt
xinfo_object_decl:
"(" xinfo_class_name xinfo_name ")"
xinfo_class_name:
identifier // Name of class with certain properties.
xinfo_name:
identifier // Variable scoped in following compound_stmt.
succeed_stmt:
"succeed" (return_stmt | ";")
which could conceivably support nested exceptions, a statically selected
number of retries/fallbacks, and would yield cleaner more readable
syntax, but suffers from non-local handling of failure.
In short, there is a very wide range of options for exception handling.
C++'s "try catch" has the virtue of being simple, but doesn't handle
nested exceptions, and makes it awkward to do Eiffel style handling.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?