Plan for Exceptions and @nogc?

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Wed Feb 18 12:37:34 PST 2015


On Wednesday, 18 February 2015 at 18:02:14 UTC, Jonathan Marler 
wrote:
> On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote:
>> From my POV best proposal from last lengthy discussion was to 
>> enable reference-counted non-gc-heap Exceptions. But that 
>> needs a language change because RefCounted!T is a struct and 
>> thus neither can be thrown nor can be part of Throwable class 
>> hierarchy.
>>
>> Any concept that implies that exceptions an be deallocated in 
>> `catch` block is absolutely unacceptable because it conflicts 
>> with exception propagation from fibers - a very important 
>> piece of functionality.
>
> RefCounted Exceptions would work quite nicely.  You are right 
> that It will require work on the language to support them but I 
> like that solution.

It will likely trigger whole load of other issues being totally 
new language concept but so far I am not aware of any better 
proposal.

Of course to truly address @nogc you need also some sort of 
object pool for exceptions instances where those get returned 
upon release - otherwise it would simply move allocations from GC 
heap to plain heap. Which you can do already and does not really 
fix the problem.

But that is a relatively simple library solution that can be 
built if reference counted exception become reality.

> If you don't mind, could you explain why cleaning up exception 
> in the catch block would break exception propogation from 
> fibers.  Are you saying that if you throw inside a catch block 
> and save a reference to the exception (in the new exceptions 
> "next" field), that it will create a dangling pointer?

Imagine application like vibe.d which uses fibers to imitate 
blocking API for async operations (we have something similar in 
Sociomantic projects too). Callbacks execute in the context of 
event loop but if any of those throws you want exception trace to 
point to original "blocking" call that registered callback.

Right now doing this is relatively simple. You catch all 
exception in callbacks and store exception instance in relevant 
fiber-local data. Upon resuming that fiber it checks if there are 
any pending exceptions and re-throws if there is one. There are 
probably more tricky details but basic principle should be like 
this.


More information about the Digitalmars-d mailing list