On Tuesday, 17 February 2015 at 21:30:00 UTC, Matthias Bentrup
wrote:
On Tuesday, 17 February 2015 at 20:48:07 UTC, Jonathan Marler
wrote:
That would work if you didn't have to unwind the stack but
unfortunately you do. The catch block exists in the context
of the function it is written in. That means it assumes the
stack pointer and stack variables are all in the context of
it's defining function. If you executed the catch code when
the stack wasn't unwound, then it wouldn't know where any of
the variables were. Does that make sense? Think about it for
a minute. You proposal suggests that the catch code can be
executed no matter how many child functions have been added to
the stack. This is impossible since the catch code no longer
knows where all of it's stack variables are. Normally it uses
an offset to the stack pointer but now it has been changed.
That's why you have to unwind the stack.
So the catcher would have to behave like a delegate.
Sure but then you're allocating GC memory again (compounding the
problem you're trying to solve in the first place). The best
solution I can think of that should work in almost every case is
to allocate the exception on the non-GC heap, then make the
catcher cleans up the exception. Simple, and makes sense when
you think about the lifetime of an exception. This would have
been dangerous before but with the new scope semantics D can
ensure that the exception does not escape the catch block (and
therefore gets cleaned up properly).
