Didn't we have a similar discussion all the way back when we were considering whether IO cancellation should be modeled as a "catchable" C++ exception?
On Tue, Sep 6, 2016 at 12:39 PM, Richard Smith <[email protected]> wrote: > On 6 September 2016 at 11:56, John McCall <[email protected]> wrote: > >> > On Sep 6, 2016, at 11:50 AM, Thiago Macieira <[email protected]> wrote: >> > Em terça-feira, 6 de setembro de 2016, às 11:38:43 PDT, John McCall >> escreveu: >> >> This would be inappropriate; the appropriate solution would be to ask >> the >> >> committee for a new function in namespace std that could be implemented >> >> with abi::__forced_unwind. I believe that's the chief purpose of that >> >> function, to allow that sort of functionality to be implemented in the >> >> future. >> >> >> >> If std::current_exception works, of course, all the better. >> > >> > I will post to std-discussion and see if there's a consensus. I'm not >> sure >> > there can be because this is outside of the C++ language: there's no >> such >> > thing as forced unwinds in the standard. >> >> Hmm. I think this used to not be true; there were library features (e.g. >> longjmp) >> that were allowed, but not required, to be implemented by unwinding the >> stack. >> But now it seems that these places have all been changed to specify >> undefined >> behavior if they would bypass any non-trivial destructors. >> > > That's true, but it does not place restrictions on intervening 'catch > (...)' blocks, and (since no exception has been thrown) they presumably > must /not/ be entered. (You don't get UB from a longjmp where a > corresponding throw would enter a catch(...) block -- although that may > just be a wording defect.) > > The possibility of forced unwinding invoking a 'catch (...)' block with no > current exception seems broken to me. For instance, this may or may not > call terminate() if f() results in a forced unwind, depending on how > 'throw;' is implemented: > > try { > f(); > } catch (...) { > log_error(); // might reasonably assert(std::current_exception()) > throw; > } > > Pretending that a forced unwind throws a C++ exception of some known type > seems likely to be the best approach -- and I'd expect that exception to be > capturable via std::current_exception and counted by > std::uncaught_exceptions, or exception-safe code using those facilities > will not function correctly in the presence of a forced unwind. (And > likewise for foreign exceptions; we presumably want to pretend that they > are just like C++ exceptions but are of a type that doesn't match that of > any handlers.) > > _______________________________________________ > cxx-abi-dev mailing list > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > >
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
