Proposal: Exceptions and @nogc

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Apr 2 13:35:27 PDT 2017


On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:
> Copy means allocate and then deallocate in the catch, defeating the whole
> propose of preallocating.

That's right.


> Would it be possible to just set a bit somewhere that
> indicates that the exception is preallocated and need not be freed.

Yes, it's possible. But I'd have to be convinced that there isn't some other 
problem with a design that requires preallocated exceptions.

Exceptions are slow; they are designed to totally favor the non-throwing path. 
Walking the stack and looking through the tables looking for the right stack 
frame information is slow. Unwinding is slow. The druntime exception handling 
code is dog slow (it's just as agonizing in C++, it's not a D thang).

If the D exception allocator uses a pool, and exceptions are held to being just 
a few bytes long (they can always use PIMPL if they have large data 
requirements), they'll be very cheap to allocate and initialize. It's hard to 
see how that would be a problem, given the rest of what goes on in 
throwing/unwinding.

I can see preallocated exceptions needed for avoiding GC and hence an adversely 
timed GC pause/collect cycle. But with this proposal, I can't see the value.


More information about the Digitalmars-d mailing list