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