rjmccall added a comment. In D108905#2973066 <https://reviews.llvm.org/D108905#2973066>, @modimo wrote:
> In D108905#2971861 <https://reviews.llvm.org/D108905#2971861>, @rjmccall > wrote: > >> I'm not really sure what the standard expects to happen if an exception >> destructor throws. The standard tells us when the destruction happens — the >> latest point it can — but that clause doesn't mention exceptions from the >> destructor. If there's a specific clause on this, I can't find it. >> [except.throw]p7 says that "if the exception handling mechanism handling an >> uncaught exception directly invokes a function that exits via an exception, >> the function std::terminate is called", which is meant to cover exceptions >> thrown when initializing a catch variable. Once the catch clause is >> entered, though, the exception is considered caught unless it's rethrown, so >> this clause doesn't apply when destroying the exception at the end of the >> clause. > > Scanning through the standard this to me also looks like an overlooked corner > case in the standard (TBF this is very corner case). > >> If the catch variable's destructor throws, that seems to be specified to >> unwind normally (including destroying the exception, and if the destructor >> throws at that point then std::terminate gets called, as normal for >> exceptions during unwinding). > > In this case, the destructor is throwing during normal scope exit so I don't > think terminate behavior from [except.throw]p7 is enforced since we're not > currently handling an uncaught exception. The handler is already active since > we're past the initialization of the catch. Given that, I think this is akin > to the example in [except.ctor]p2 and if the destructor is `noexcept(false)` > should trigger a proper unwind like how an exception in the destructor of a > simple automatic variable inside the handler scope would also do. Yeah, I think this is the most natural interpretation of the current standard. But that would be a very unfortunate rule, because people who write `catch (...) {}` do reasonably expect that that code will never throw. In fact, it would be quite difficult — perhaps impossible — to write code that actually swallowed all exceptions: even `try { try { foo() } catch(...) {} } catch (...) {}` wouldn't work, because you could throw an exception whose destructor throws an exception whose destructor throws an exception ad infinitum. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108905/new/ https://reviews.llvm.org/D108905 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
