* 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 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?