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.

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