This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EH in egcs
- To: hjl at lucon dot org
- Subject: Re: EH in egcs
- From: mrs at wrs dot com (Mike Stump)
- Date: Mon, 27 Oct 1997 16:21:51 -0800
- Cc: egcs at cygnus dot com
Sorry, you don't understand C++'s requirements well enough to come up
with a design that will work. The below is flawed.
One needs to have a stack of outstanding exceptions, and push/pop
elements of that stack at the right times (roughly speaking, push upon
first throw and pop upon exist of the last matching catch block).
__eh_{type,pc} and friends are then just the top elements of this
stack.
> From: hjl@lucon.org (H.J. Lu)
> To: law@cygnus.com
> Date: Sun, 26 Oct 1997 12:33:48 -0800 (PST)
> Cc: jason@cygnus.com, egcs@cygnus.com
> Although EH is much better than before, it still needs some improvement,
> especially what happens after the exception is caught. There are 2
> test cases which show the problem. That is nested throw/catch doesn't
> work. That is because __eh_value/__eh_type are used throughout
> EH and the new ones will override the old ones. I was wondering if
> we could do this in the catch region:
> Treat the caught exception as a local variable. That is make
> catch (type caught)
> {
> }
> equivalent to
> foo ()
> {
> type caught;
> }
> Can we use __eh_value/__eh_type to make it to work? After that,
> caught will be handled just like any other local variables.
> If there is another exception thrown inside foo (), caught
> will be cleared appropriately. Otherwise, it will be cleared
> when exception is out of scope.