On 15 March 2012 00:19, Brad Roberts <[email protected]> wrote: > Actually, the interaction of errors with @nothrow is a very specific part > of the problem. @nothrow allows the compiler to NOT setup the > infrastructure to catch throwables at all. This allows for some useful > optimizations. So, saying that Errors can be caught means that they have > to be dis-allowed in @nothrow functions too.
That seems easily fixable to me. Since nothrow is transitive, cases where an Error is thrown are always known. In ThrowStatement:toIR() in s2ir.c, could check if it's a nothrow function and call a separate function, rather than _d_throwc, for an Error thrown inside a nothrow function. This could do nothing more than set a flag 'thrown from nothrow'/'unsafe' inside Error. That leaves only the case of system exceptions on Windows. Conservatively, they could also be set to 'unsafe'. Really if you're going to catch one of those guys, you'd better catch them right next to the event anyway. The 'unsafe' flag may or may not affect stack unwinding (Maybe that could even be a setting in the runtime). But regardless, the catch handler would at least know if it could be sure that stack unwinding had happened, or not. Then, if we do this, it remains safe to catch an AssertError from a unit test. Are there any other issues? _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
