On Tuesday, 17 February 2015 at 17:38:20 UTC, Jonathan Marler
wrote:
The reason you can't keep the "thrower's" stack memory around
for the exception handler is because the exception handler may
need that memory. Once the exception is thrown the stack is
unwound to the function that has the exception handler so all
the memory gets released. In most cases the exception handler
probably won't mess up the memory the exception is using, but
that can't be guaranteed.
The problem I see, is that if I program a @nogc function for
performance reasons, I'll likely have some data in scoped memory
that is useful for handling the exception. If the stack is
unwound before the exception handler, the thrower has to copy it
to non-scoped memory and the catcher has to deal with it whether
it needs the data or not.
If the unwinding is done after the exception handler is left, the
thrower can safely reference the data directly on the stack and
the catcher can ignore any data it doesn't need. (It may copy the
data to safety if it is needed later, but the catcher knows what
it needs, whereas the thrower has to always assume the worst
case.)
