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.
