Topic: Clarification needed for 18.6.4: terminate() and uncaught_excaption()


Author: Eric Niebler <eric@boost-consulting.com>
Date: Mon, 6 Aug 2007 17:16:54 CST
Raw View
The question is regarding the behavior of the following program.

     #include <cstdio>
     #include <cstdlib>
     #include <exception>

     struct E {};

     void t()
     {
         if (!std::uncaught_exception())
             std::printf("HERE\n");
         std::exit(0);
     }

     int main()
     {
         E e;
         std::set_terminate(&t);
         throw e;
     }

Should it print "HERE"? This is the relevant part of the standard
(18.6.4, or for those looking at the working paper, 18.7.4):

   bool uncaught_exception() throw();

   Returns: true after completing evaluation of a
   throw-expression until either completing
   initialization of the exception-declaration in
   the matching handler or entering unexpected()
   due to the throw; or after entering terminate()
   for any reason other than an explicit call to
   terminate().


I can read this two ways:

1) Returns true after <blah> or after entering terminate() ...
2) Returns true after <blah> until either ... or after entering
terminate() ...

If I choose the second reading, the program should print "HERE". If I
choose the first, it shouldn't. What is the intention?

FWIW, the compilers I have available to me (metrowerks, visual c++, g++)
seem to agree with the second reading, but a well-respected conformance
testing suite interprets this the other way.

--
Eric Niebler
Boost Consulting
www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com

---
[ 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.comeaucomputing.com/csc/faq.html                      ]





Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Wed, 8 Aug 2007 03:19:02 GMT
Raw View
Eric Niebler ha scritto:
>
>   bool uncaught_exception() throw();
>
>   Returns: true after completing evaluation of a
>   throw-expression until either completing
>   initialization of the exception-declaration in
>   the matching handler or entering unexpected()
>   due to the throw; or after entering terminate()
>   for any reason other than an explicit call to
>   terminate().
>
>
> I can read this two ways:
>
> 1) Returns true after <blah> or after entering terminate() ...
> 2) Returns true after <blah> until either ... or after entering
> terminate() ...
>
> If I choose the second reading, the program should print "HERE". If I
> choose the first, it shouldn't. What is the intention?

FWIW, I believe the intent is the first one, for two reasons:

1) the semicolon is a strong suggestion that the second "or..." is not
related with the preceding "either... or..." construct, but rather an
alternative to the entire phrase starting with "after completing...". If
it was meant the other way, then there would be no semicolon.

2) with reading number 2, uncaught_exception() will never be true inside
terminate(), whether the call has been explicit or not. Checking
uncaught_exception() inside terminate() might be of some use, so why
lose such capability? Moreover, the phrase "for any reason other than an
explicit call" would be redundant. I don't think a phrase complex such
as that might slip in by mistake.

> FWIW, the compilers I have available to me (metrowerks, visual c++, g++)
> seem to agree with the second reading, but a well-respected conformance
> testing suite interprets this the other way.

If I'm not mistaken, versions of VC++ up to and including 7.1 do not
even implement uncaught_exception(): it always returns false (see
http://msdn2.microsoft.com/en-us/library/aa903425(VS.71).aspx). As for
others, I think that's a bug.

Just my opinion,

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]





Author: ymett <ymett.on.usenet@gmail.com>
Date: Wed, 8 Aug 2007 09:36:28 CST
Raw View
On Aug 8, 6:19 am, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Eric Niebler ha scritto:
> >   bool uncaught_exception() throw();
>
> >   Returns: true after completing evaluation of a
> >   throw-expression until either completing
> >   initialization of the exception-declaration in
> >   the matching handler or entering unexpected()
> >   due to the throw; or after entering terminate()
> >   for any reason other than an explicit call to
> >   terminate().
>
> > I can read this two ways:
>
> > 1) Returns true after <blah> or after entering terminate() ...
> > 2) Returns true after <blah> until either ... or after entering
> > terminate() ...
>
> > If I choose the second reading, the program should print "HERE". If I
> > choose the first, it shouldn't. What is the intention?
>
> FWIW, I believe the intent is the first one, for two reasons:
.
> 2) with reading number 2, uncaught_exception() will never be true inside
> terminate(), whether the call has been explicit or not. Checking
> uncaught_exception() inside terminate() might be of some use, so why
> lose such capability? Moreover, the phrase "for any reason other than an
> explicit call" would be redundant.

No. uncaught_exception() will be true inside terminate() if
terminate() is called explicitly while unwinding the stack. That might
be more useful (or might not; I don't actually see much use either
way).

In fact, with reading #1 it seems redundant, because when is
terminate() called implicitly that wouldn't be covered by the first
part of the paragraph?

Yechezkel Mett

---
[ 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.comeaucomputing.com/csc/faq.html                      ]