[dmd-internals] Throwing Errors

Don Clugston dclugston at googlemail.com
Thu Mar 15 02:53:25 PDT 2012


On 15 March 2012 00:19, Brad Roberts <braddr at puremagic.com> 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?


More information about the dmd-internals mailing list