Exceptions in @nogc code

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Apr 2 10:21:37 PDT 2017


On 4/1/17 2:18 PM, Dmitry Olshansky wrote:
> I don't understand what's so difficult to just recognize that "throw new
> Exception" creates a unique object that is passed to the exception
> handler.

That would be a good possibility: default to creating exceptions as 
scope objects, speculating that the catch site may also be scope. If the 
catch site does not use scope, then clone into a heap object. This is 
speculative, but the cost of cloning is much smaller than the cost of 
the allocation so it's not a large loss.

> So just mark the exception as unique in the exception handler
> code so that catch site is aware of it. Are we just bend on penalizing
> programmers for not typing out "scope"?

A catch site that does not use "scope" has more freedom, e.g.:

void fun()
{
     static Exception last;
     try { ... }
     catch (Exception e) { last = e; }
     ...
}

Such is not possible with a scoped catch. Of course, that's a concern 
only if we want to preserve backwards compatibility.

> In turn I don't see what adding "scope" to the catch site accomplishes -
> you still need to ensure the reference doesn't escape.

You don't. Old code behaves as it always did.

> And if it doesn't
> escape you may just as well deallocate the exception object.

Ah, so here we're looking at a deduction scheme. Most interesting! First 
try to see if "scope" would work (even if not written), and if so just 
consider it there.

>> Such a scheme preserves backward compatibility and leverages the work
>> done on "scope".
>
> Pardon but I don't see how.

Think again - checks and e.g. deduction (if we add it as you suggested 
above) would work pretty much out of the box.


Andrei



More information about the Digitalmars-d mailing list