Namespaces
Variants
Views
Actions

Talk:cpp/error/uncaught exception

From cppreference.com

The description states that "Sometimes it's safe to throw an exception even while std::uncaught_exception() == true", but the example - "if exceptions are caught and ignored in a destructor, they can't propagate out of it and won't lead to std::terminate" - doesn't seem to relate to the assertion. Is it unclear or unrelated? 92.235.157.64 13:40, 22 November 2012 (PST)

It's exactly the case when it is safe: suppose stack unwinding is in progress and a destructor of some local object is called. In the body of that destructor, there is a call to a potentially throwing function, surrounded in a try/catch(...). The destructor calls that potentially-throwing function, and inside that function, uncaught_exception() == true, but it's safe to throw. I suppose it's unclear, tried to edit for clarity. --Cubbi 19:16, 22 November 2012 (PST)
Ahh yes, didn't think of being inside a try..catch in a destructor during stack unwinding. Silly brain. Thanks for the edit - clarification works fine. 92.235.157.64 15:47, 24 November 2012 (PST)

[edit] Accuracy detection of stack unwinding durning destruction

Hello everyone!

I suppose that class Foo from the sample in the article cannot correctly detect if there is stack unwinding during destruction.

To prove myself I make a little demo, that shows two cases where this class was correct and two more cases where it wasn't.

https://godbolt.org/z/GEaYn6Mcz

And I think it's not so synthetic example and it can be met in a real program.

And because we can make a very synthetic function that can run any code with any value of uncaught_exceptions() (see example 5 in code from the link above), I suppose that we cannot use a result of uncaught_exceptions() to make any predictions about stack unwinding in the general case.

I suppose that Foo detection works only if it was created on the stack without moving or copying.

the example in the page is demoing the use case this function was designed for, as found in boost.log (ok, they use >= instead of !=, guess we could too). And I see boost.leaf got it, too. Yes indeed it can be subverted. Nice demo. --Cubbi (talk) 20:08, 6 August 2021 (PDT)