Hi all,

Standard says:
15.3/9

If no matching handler is found in a program, the function terminate()
is called; whether or not the stack is unwound before this call to
terminate() is implementation defined (15.5.1).


Anyone knows the rationale for letting the implementation decide
whether to do stack unwinding or not?
Why aren't all implemetations required to do stack unwinding first?

Best,
John


John Torjo
Freelancer
-- john@torjo.com

Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/

Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging           - C++)
-- http://www.torjo.com/logview/         (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/        (debugging         - Win32)
                                         (source code available)

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Torjo wrote:

> If no matching handler is found in a program, the function terminate()
> is called; whether or not the stack is unwound before this call to
> terminate() is implementation defined (15.5.1).
>
>
> Anyone knows the rationale for letting the implementation decide
> whether to do stack unwinding or not?
> Why aren't all implemetations required to do stack unwinding first?

The case "no matching handler" usually means, that the
unexpected-unexpected happened [think of an implementation defined
exception for hardware errors...]. So it's not foreseeable, if
stack-unwinding will make things worser than they are or not, and the
standard doesn't know either.

Regards
Marco


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Torjo wrote:

> Standard says:
> 15.3/9
>
> If no matching handler is found in a program, the function terminate()
> is called; whether or not the stack is unwound before this call to
> terminate() is implementation defined (15.5.1).
>
> Anyone knows the rationale for letting the implementation decide
> whether to do stack unwinding or not?
> Why aren't all implemetations required to do stack unwinding first?


You can't inspect the terminated program to find the where or why the
uncaught exception occurred if the stack is unwound before the problem
is reported. That is, a debugger or core file inspection can't tell
you anything because the program stack is gone.

This clause in the standard allows the implemention to do whatever
makes the most sense for its clients. For example, a compiler or
run-time option might control whether the stack is unwound. When
running under a debugger you would not want the stack to be unwound on
an uncaught exception.

---
Steve Clamage, stephen.clamage@sun.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 04 Aug 2004 07:56:41 -0700, John Torjo wrote:

 > Standard says:
 > 15.3/9
 >
 > If no matching handler is found in a program, the function terminate()
 > is called; whether or not the stack is unwound before this call to
 > terminate() is implementation defined (15.5.1).
 >
 >
 > Anyone knows the rationale for letting the implementation decide whether
 > to do stack unwinding or not? Why aren't all implemetations required to
 > do stack unwinding first?

I think this is because both approaches have merit. The best
would be to be able to pick.

In the past, I worked on a g++ 2.96 project where keeping the
stack intact would be very helpful when the program terminated
with an uncaught exception. Unfortunately though, when this
happens, g++ 2.96 does unwind the stack and all the information
about the bad state of the program is lost.

Ali

P.S. I have a vague feeling that the newer versions of g++ let
the user pick the behavior but I am too lazy to check now :/


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Torjo" <jtorjo@yahoo.com> wrote in message
news:c638aac5.0408032247.6fbb8825@posting.google.com...

 > Anyone knows the rationale for letting the implementation decide
 > whether to do stack unwinding or not?
 > Why aren't all implemetations required to do stack unwinding first?

Because if you unwind the stack before you discover that the exception isn't
being handled, then by the time your debugger gets control, the key
information has been lost.  On the other hand, if you're not debugging, it
may be more efficient to unwind each level of the stack before deciding
whether the next level handles the current exception.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jtorjo@yahoo.com (John Torjo) wrote in message news:<c638aac5.0408032247.6fbb8825@posting.google.com>...
 > Hi all,
 >
 > Standard says:
 > 15.3/9
 >
 > If no matching handler is found in a program, the function terminate()
 > is called; whether or not the stack is unwound before this call to
 > terminate() is implementation defined (15.5.1).
 >
 >
 > Anyone knows the rationale for letting the implementation decide
 > whether to do stack unwinding or not?
 > Why aren't all implemetations required to do stack unwinding first?
 >

Do you want the stack to be unwound?  If nobody can handle the
exception properly, then the destructors of the stack based object may
run into trouble.  Perhaps it is better in the face of an exception
that can not be handled to simply terminate() the program as soon as
possible.

joshua lehrer
factset research systems
NYSE:FDS


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Torjo wrote:
 >
 > Hi all,
 >
 > Standard says:
 > 15.3/9
 >
 > If no matching handler is found in a program, the function terminate()
 > is called; whether or not the stack is unwound before this call to
 > terminate() is implementation defined (15.5.1).
 >
 >
 > Anyone knows the rationale for letting the implementation decide
 > whether to do stack unwinding or not?
 > Why aren't all implemetations required to do stack unwinding first?

If the implementation unwinds before calling terminate() then the
context of the exception is lost and any dump file is of little use in
debugging.  So the non-unwinding behaviour is desirable.  However, a
simple "SJLJ" (setjmp/longjmp) implementation of exceptions cannot
search for exception handlers without unwinding along the way, so
unwinding is permitted to avoid ruling them out.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Torjo wrote:
[...]
 > Why aren't all implemetations required to do stack unwinding first?

It makes no sense. Use terminate() handlers to "play with"
emergency cleanup of external resources (works more or less
okay with noncritical stuff like turning off the PC speaker).

For serious stuff, isolate emergency cleanup and recovery in
a separate "program". High availability, you know.

regards,
alexander.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ali Cehreli wrote:

 > In the past, I worked on a g++ 2.96 project where keeping the
 > stack intact would be very helpful when the program terminated
 > with an uncaught exception. Unfortunately though, when this
 > happens, g++ 2.96 does unwind the stack and all the information
 > about the bad state of the program is lost.

I'm using gcc-3.1.1, and it doesn't unwind the stack on an uncaught
exception, so gdb can tell you exactly where the exception was thrown.
This is pretty useful when std::vector throws an out-of-bounds error.

-Ed

--
(You can't go wrong with psycho-rats.)       (er258)(@)(eng.cam)(.ac.uk)

/d{def}def/f{/Times findfont s scalefont setfont}d/s{10}d/r{roll}d f 5/m
{moveto}d -1 r 230 350 m 0 1 179{1 index show 88 rotate 4 mul 0 rmoveto}
for /s 15 d f pop 240 420 m 0 1 3 { 4 2 1 r sub -1 r show } for showpage


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]