public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/41174]  New: uncaught_exception always returns true
@ 2009-08-26  6:20 wwashby at earthlink dot net
  2009-08-26 15:31 ` [Bug c++/41174] " redi at gcc dot gnu dot org
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: wwashby at earthlink dot net @ 2009-08-26  6:20 UTC (permalink / raw)
  To: gcc-bugs

C:\...>gcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)

Build command line:  gpp -oexcpt -DTESTBADE excpt.C

Execute command line:  excpt

The following source code is a pared down version of a short program I wrote to
try the boundaries of the functions in <exception>.  An exception object's
constructor itself throws and catches an exception.  After that,
uncaught_exception always returns true.  In the "Output:" comment at the end of
the source file, places where uncaught_exception should return false are marked
with "!!!".

// excpt.C uses exceptions in strange and unusual ways
//
// build command line:  gpp -oexcpt -DTESTBADE excpt.C
// execute command line:  excpt

#include <iostream>
#include <exception>

void uncaught(int i = 0)
{
    std::cerr << "[" << i <<"] std::uncaught_exception() = " << std::boolalpha
        << std::uncaught_exception() << std::endl;
}

class E {
    const char* descr;

public:
    E(const char* str): descr(str)
    {
        std::cerr << "E::E(\"" << descr << "\")\n";
        uncaught();    }
    E(const E& e): descr(e.descr)
    {
        std::cerr << "E::E(const E&)\n";
        uncaught();
    }
    ~E()
    {
        std::cerr << "E::~E()\n";
        uncaught();
    }
    const char* describe() { return descr; }
};

/*****************************************************/
#ifdef TESTBADE
class BadE {
    const char* str;

public:
    BadE(const char* s)
    try
        : str(s)
    {
        std::cerr << "BadE::BadE(const char*) throwing \"thrown by
Bade::BadE(const char*)\"\n";
        throw "thrown by BadE::BadE(const char*)";
    }
    catch (const char* str) {
        std::cerr << "BadE::BadE(const char*) caught \"" << str << "\"\n";
    }

    ~BadE()
    {
        std::cerr << "BadE::~BadE()\n";
    }

    const char* describe() { return str; }
};

void throwBadE()
{
    std::cerr << "throwBadE():  throw BadE(\"thrown by throwBadE()\")\n";
    throw BadE("thrown by throwBadE()");
}
#endif
/*****************************************************/

void x(int i)
{
    try {
        std::cerr
            << "[" << i <<"] x(int) throwing E(\"E from x(int) try block\")\n";
        throw E("E from x(int) try block");
    }
    catch (E e) {
        std::cerr << "[" << i <<"] x(int) entering catch (E) block\n";
        uncaught(i);
        std::cerr << "[" << i <<"] x(int) caught E(\"" << e.describe() << "\")
by value\n";
        uncaught(i);
        std::cerr << "[" << i <<"] x(int) exiting catch (E) block\n";
    }
    std::cerr << "[" << i << "] x(int) tries uncaught before exiting\n";
    uncaught(i);
}

int main()
{
    x(1);
#ifdef TESTBADE
/*****************************************************/
    std::cerr << "*****************************************************\n";
    try {
        std::cerr << "main() calling void throwBadE();\n";
        try {
            throwBadE();
        }
        catch (BadE& be) {
            std::cerr << "catch (BadE&) block => \"" << be.describe() <<
"\"\n";
        }
        catch (const char* str) {
            std::cerr << "catch (const char*) block:  " << str << "\n";
        }
        catch (...) {
            std::cerr << "catch (...) block after calling void throwBadE();\n";
        }
    }
    catch (...) {
        std::cerr << "catch (...) looking for leftover exceptions ???\n";
    }
/*****************************************************/
#endif
    std::cerr << "*****************************************************\n";
    x(2);
    std::cerr << "*****************************************************\n";
    std::cerr << "before returning from main() check uncaught\n";
    uncaught(3);
}

/*
Output:

[1] x(int) throwing E("E from x(int) try block")
E::E("E from x(int) try block")
[0] std::uncaught_exception() = true
E::E(const E&)
[0] std::uncaught_exception() = true
[1] x(int) entering catch (E) block
[1] std::uncaught_exception() = false
[1] x(int) caught E("E from x(int) try block") by value
[1] std::uncaught_exception() = false
[1] x(int) exiting catch (E) block
E::~E()
[0] std::uncaught_exception() = false
E::~E()
[0] std::uncaught_exception() = false
[1] x(int) tries uncaught before exiting
[1] std::uncaught_exception() = false
*****************************************************
main() calling void throwBadE();
throwBadE():  throw BadE("thrown by throwBadE()")
BadE::BadE(const char*) throwing "thrown by Bade::BadE(const char*)"
BadE::BadE(const char*) caught "thrown by BadE::BadE(const char*)"
catch (const char*) block:  thrown by BadE::BadE(const char*)
*****************************************************
[2] x(int) throwing E("E from x(int) try block")
E::E("E from x(int) try block")
[0] std::uncaught_exception() = true
E::E(const E&)
[0] std::uncaught_exception() = true
[2] x(int) entering catch (E) block
[2] std::uncaught_exception() = true                      !!!
[2] x(int) caught E("E from x(int) try block") by value
[2] std::uncaught_exception() = true                      !!!
[2] x(int) exiting catch (E) block
E::~E()
[0] std::uncaught_exception() = true                      !!!
E::~E()
[0] std::uncaught_exception() = true                      !!!
[2] x(int) tries uncaught before exiting
[2] std::uncaught_exception() = true                      !!!
*****************************************************
before returning from main() check uncaught
[3] std::uncaught_exception() = true                      !!!
*/


-- 
           Summary: uncaught_exception always returns true
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wwashby at earthlink dot net
 GCC build triplet: same
  GCC host triplet: Microsoft Windows XP Home Edition, x86 Family 16 Model 2
                    Steppin
GCC target triplet: same


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug c++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
@ 2009-08-26 15:31 ` redi at gcc dot gnu dot org
  2009-08-26 15:52 ` redi at gcc dot gnu dot org
                   ` (13 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-26 15:31 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from redi at gcc dot gnu dot org  2009-08-26 15:31 -------
Reduced:

#include <cassert>
#include <exception>

struct GoodE {
    GoodE()
    {
        try {
            throw 1;
        } catch (...) {
        }
    }
};

struct BadE {
    BadE()
        try {
            throw 1;
        } catch (...) {
        }
};

int main()
{
    try {
        throw GoodE();
    } catch (...) {
        assert( !std::uncaught_exception() );
    }

    try {
        throw BadE();
    } catch (...) {
        assert( !std::uncaught_exception() );
    }
}

Note that GoodE doesn't cause the problem. The difference is that BadE has a
function-try-block


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug c++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
  2009-08-26 15:31 ` [Bug c++/41174] " redi at gcc dot gnu dot org
@ 2009-08-26 15:52 ` redi at gcc dot gnu dot org
  2009-08-26 16:01 ` redi at gcc dot gnu dot org
                   ` (12 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-26 15:52 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from redi at gcc dot gnu dot org  2009-08-26 15:52 -------
It looks as though uncaught_exception() does not always become false when
entering the handler of a function-try-block, and this causes it to stay true.

Maybe the count of uncaught exceptions is not decremented in the
function-try-block's handler, but is incremented when the exception is rethrown
at the end of the handler, causing it to be one more than it should not be.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug c++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
  2009-08-26 15:31 ` [Bug c++/41174] " redi at gcc dot gnu dot org
  2009-08-26 15:52 ` redi at gcc dot gnu dot org
@ 2009-08-26 16:01 ` redi at gcc dot gnu dot org
  2009-08-26 16:18 ` redi at gcc dot gnu dot org
                   ` (11 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-26 16:01 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from redi at gcc dot gnu dot org  2009-08-26 16:01 -------
(In reply to comment #2)
> at the end of the handler, causing it to be one more than it should not be.

Oops, obviously I meant "one more than it should be"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug c++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (2 preceding siblings ...)
  2009-08-26 16:01 ` redi at gcc dot gnu dot org
@ 2009-08-26 16:18 ` redi at gcc dot gnu dot org
  2009-08-26 16:50 ` redi at gcc dot gnu dot org
                   ` (10 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-26 16:18 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from redi at gcc dot gnu dot org  2009-08-26 16:17 -------
(In reply to comment #1)
> Note that GoodE doesn't cause the problem. The difference is that BadE has a
> function-try-block

And, of course, that the exception is rethrown by BadE at the end of the
handler. Changing GoodE to rethrow makes it have the same behaviour, so it's
not specific to function-try-blocks.

I give up for now, I'll just link to bug 10606 and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#475 for reference


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug c++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (3 preceding siblings ...)
  2009-08-26 16:18 ` redi at gcc dot gnu dot org
@ 2009-08-26 16:50 ` redi at gcc dot gnu dot org
  2009-08-27 10:37 ` [Bug libstdc++/41174] " redi at gcc dot gnu dot org
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-26 16:50 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from redi at gcc dot gnu dot org  2009-08-26 16:50 -------
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before entering the exception's constructor.
 If the exception constructor throws another exception then uncaughtExceptions
goes to 2, and never goes back to zero.

uncaught_exception() should return true after evaluating the operand of throw.
If the operand cannot be constructed (because it throws) then that evaluation
never completes.

My understanding is that this should run to completeion, but all four
assertions fail:

#include <cassert>
#include <exception>

struct e {
    e()
    {
        assert( !std::uncaught_exception() );
        try {
            throw 1;
        } catch (int i) {
            assert( !std::uncaught_exception() );
            throw;
        }
    }
};

int main()
{
    try {
        throw e();
    } catch (int i) {
        assert( !std::uncaught_exception() );
    }
    assert( !std::uncaught_exception() );
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (4 preceding siblings ...)
  2009-08-26 16:50 ` redi at gcc dot gnu dot org
@ 2009-08-27 10:37 ` redi at gcc dot gnu dot org
  2009-08-27 10:51 ` paolo dot carlini at oracle dot com
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-27 10:37 UTC (permalink / raw)
  To: gcc-bugs



-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |libstdc++
     Ever Confirmed|0                           |1
  GCC build triplet|same                        |
   GCC host triplet|Microsoft Windows XP Home   |
                   |Edition, x86 Family 16 Model|
                   |2 Steppin                   |
 GCC target triplet|same                        |
      Known to fail|                            |4.3.4 4.4.1 4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-27 10:37:03
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (5 preceding siblings ...)
  2009-08-27 10:37 ` [Bug libstdc++/41174] " redi at gcc dot gnu dot org
@ 2009-08-27 10:51 ` paolo dot carlini at oracle dot com
  2009-08-27 11:37 ` redi at gcc dot gnu dot org
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-08-27 10:51 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from paolo dot carlini at oracle dot com  2009-08-27 10:51 -------
Is this related to PR 37477?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (6 preceding siblings ...)
  2009-08-27 10:51 ` paolo dot carlini at oracle dot com
@ 2009-08-27 11:37 ` redi at gcc dot gnu dot org
  2009-08-27 11:59 ` paolo dot carlini at oracle dot com
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-27 11:37 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from redi at gcc dot gnu dot org  2009-08-27 11:37 -------
(In reply to comment #6)
> Is this related to PR 37477?

It looks like a slightly different issue.  PR 37477 relates to when
uncaught_exception() stops being true and fixing it might need to wait for the
resolution to core issue 475.

This bug relates to when uncaught_exception() starts being true, and I don't
think it depends on issue 475 (although it might make sense to wait for a
resolution anyway.)
The table in issue 475 would show today's GCC as "1 1 1 1 ABRT" and I believe
that first "1" is wrong and is the root cause of this bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (7 preceding siblings ...)
  2009-08-27 11:37 ` redi at gcc dot gnu dot org
@ 2009-08-27 11:59 ` paolo dot carlini at oracle dot com
  2009-08-27 12:18 ` redi at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-08-27 11:59 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from paolo dot carlini at oracle dot com  2009-08-27 11:59 -------
As a general rule, if we are sure about the dependency on a DR, we suspend the
PR and remember the DR # in the Summary.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (8 preceding siblings ...)
  2009-08-27 11:59 ` paolo dot carlini at oracle dot com
@ 2009-08-27 12:18 ` redi at gcc dot gnu dot org
  2009-08-27 14:27 ` wwashby at earthlink dot net
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-27 12:18 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from redi at gcc dot gnu dot org  2009-08-27 12:18 -------
(In reply to comment #5)
> I think the problem is that the uncaught_exception() is true as soon as the
> memory for the exception has been allocated, but if the exception's copy
> constructor is elided then happens before entering the exception's constructor.
>  If the exception constructor throws another exception then uncaughtExceptions
> goes to 2, and never goes back to zero.

After re-reading [except.throw] and [except.terminate] I think it is OK to
elide the copy of the thrown object into the exception object here:
   throw e();
This means that uncaught_exception() can be true in the call e::e()

*But* if the copy is elided and e::e() throws then std::terminate() should be
called. This means the OP's testcase and my one in comment #5 should terminate,
rather than exiting normally with std::uncaught_exception()==true

This is because of the following in [except.terminate]/1

"when the exception handling mechanism, after completing evaluation of the
expression to be thrown but before the exception is caught (15.1), calls a
function that exits via an uncaught exception, 141"
"141) For example, if the object being thrown is of a class with a copy
constructor, std::terminate() will be called if that copy constructor exits
with an exception during a throw."

Now, either

(A) e::e() happens before completing evaluation of the expression to be thrown
and uncaught_exception() should be false during e::e()

or

(B) the copy is elided and e::e() happens after evaluating completing
evaluation. In this case, uncaught_exception() should be true during e::e() but
if it exits with an exception then std::terminate() should be called.

GCC elides the copy, but does not call std::terminate() if e::e() exits with an
exception.  I don't think this interpretation will be changed by DR 475


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (9 preceding siblings ...)
  2009-08-27 12:18 ` redi at gcc dot gnu dot org
@ 2009-08-27 14:27 ` wwashby at earthlink dot net
  2009-08-27 15:19 ` redi at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: wwashby at earthlink dot net @ 2009-08-27 14:27 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from wwashby at earthlink dot net  2009-08-27 14:27 -------
(In reply to comment #9)
> ...
> "when the exception handling mechanism, after completing evaluation of the
> expression to be thrown but before the exception is caught (15.1), calls a
> function that exits via an uncaught exception, 141"
> "141) For example, if the object being thrown is of a class with a copy
> constructor, std::terminate() will be called if that copy constructor exits
> with an exception during a throw."
> ...

I'm not sure that this applies in this situation.  An instance of BadE is
constructed because it is thrown, but BadE::BadE does not "[exit] via an
uncaught exception".  It both throws and catches an exception, and then returns
normally.  There is still an uncaught exception when BadE::BadE exits, but it
is the one that caused BadE to be constructed, not the one that BadE::BadE has
thrown (and caught).


-- 

wwashby at earthlink dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wwashby at earthlink dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (10 preceding siblings ...)
  2009-08-27 14:27 ` wwashby at earthlink dot net
@ 2009-08-27 15:19 ` redi at gcc dot gnu dot org
  2009-08-29 11:27 ` wwashby at earthlink dot net
                   ` (2 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu dot org @ 2009-08-27 15:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #11 from redi at gcc dot gnu dot org  2009-08-27 15:19 -------
(In reply to comment #10)
> 
> I'm not sure that this applies in this situation.  An instance of BadE is
> constructed because it is thrown, but BadE::BadE does not "[exit] via an
> uncaught exception".  It both throws and catches an exception, and then returns
> normally.  There is still an uncaught exception when BadE::BadE exits, but it
> is the one that caused BadE to be constructed, not the one that BadE::BadE has
> thrown (and caught).

No, in [except.handle]/16 the standard says

"The exception being handled is rethrown if control reaches the end of a
handler of the function-try-block of a constructor or destructor."

You cannot swallow exceptions in a constructor's function-try-block, they will
be rethrown.

> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (11 preceding siblings ...)
  2009-08-27 15:19 ` redi at gcc dot gnu dot org
@ 2009-08-29 11:27 ` wwashby at earthlink dot net
  2009-08-29 12:50 ` wwashby at earthlink dot net
  2010-01-08 19:14 ` paolo dot carlini at oracle dot com
  14 siblings, 0 replies; 16+ messages in thread
From: wwashby at earthlink dot net @ 2009-08-29 11:27 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from wwashby at earthlink dot net  2009-08-29 11:27 -------
(In reply to comment #11)
> (In reply to comment #10)
> > 
> > I'm not sure that this applies in this situation.  An instance of BadE is
> > constructed because it is thrown, but BadE::BadE does not "[exit] via an
> > uncaught exception".  It both throws and catches an exception, and then returns
> > normally.  There is still an uncaught exception when BadE::BadE exits, but it
> > is the one that caused BadE to be constructed, not the one that BadE::BadE has
> > thrown (and caught).
> 
> No, in [except.handle]/16 the standard says
> 
> "The exception being handled is rethrown if control reaches the end of a
> handler of the function-try-block of a constructor or destructor."
> 
> You cannot swallow exceptions in a constructor's function-try-block, they will
> be rethrown.
> 
> > 
> 
1,000 apologies, of course you are right; my own code and shows that (blush). 
Maybe uncaught_exception assumes that the throw BadE will succeed and doesn't
notice that the BadE object is not fully constructed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (12 preceding siblings ...)
  2009-08-29 11:27 ` wwashby at earthlink dot net
@ 2009-08-29 12:50 ` wwashby at earthlink dot net
  2010-01-08 19:14 ` paolo dot carlini at oracle dot com
  14 siblings, 0 replies; 16+ messages in thread
From: wwashby at earthlink dot net @ 2009-08-29 12:50 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from wwashby at earthlink dot net  2009-08-29 12:50 -------
(In reply to comment #12)
> ...
> Maybe uncaught_exception assumes that the throw BadE will succeed and doesn't
> notice that the BadE object is not fully constructed?
> 

Apparently that is the case.  Here's another test case where throw fails to
throw an exception:

#include <cstdlib>
#include <iostream>
#include <exception>

void ae()
{
    std::cerr << "At exit std::uncaught_exception() = " << std::boolalpha
        << std::uncaught_exception() << ".\n";
}

struct NoE {
    NoE() { std::exit(0); }
};


int main()
{
    std::atexit(ae);
    throw NoE();
}

/* Output:
At exit std::uncaught_exception() = true.
*/


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/41174] uncaught_exception always returns true
  2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
                   ` (13 preceding siblings ...)
  2009-08-29 12:50 ` wwashby at earthlink dot net
@ 2010-01-08 19:14 ` paolo dot carlini at oracle dot com
  14 siblings, 0 replies; 16+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-08 19:14 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #14 from paolo dot carlini at oracle dot com  2010-01-08 19:14 -------
I'm asking Rth to have a look to this one, apparently unrelated to DR Core 475.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org
           Severity|trivial                     |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2010-01-08 19:14 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-26  6:20 [Bug c++/41174] New: uncaught_exception always returns true wwashby at earthlink dot net
2009-08-26 15:31 ` [Bug c++/41174] " redi at gcc dot gnu dot org
2009-08-26 15:52 ` redi at gcc dot gnu dot org
2009-08-26 16:01 ` redi at gcc dot gnu dot org
2009-08-26 16:18 ` redi at gcc dot gnu dot org
2009-08-26 16:50 ` redi at gcc dot gnu dot org
2009-08-27 10:37 ` [Bug libstdc++/41174] " redi at gcc dot gnu dot org
2009-08-27 10:51 ` paolo dot carlini at oracle dot com
2009-08-27 11:37 ` redi at gcc dot gnu dot org
2009-08-27 11:59 ` paolo dot carlini at oracle dot com
2009-08-27 12:18 ` redi at gcc dot gnu dot org
2009-08-27 14:27 ` wwashby at earthlink dot net
2009-08-27 15:19 ` redi at gcc dot gnu dot org
2009-08-29 11:27 ` wwashby at earthlink dot net
2009-08-29 12:50 ` wwashby at earthlink dot net
2010-01-08 19:14 ` paolo dot carlini at oracle dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).