Exceptions in @nogc code

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sat Apr 1 22:09:01 PDT 2017


On 4/1/2017 7:54 AM, deadalnix wrote:
> The problem you want to address is not GC allocations, it is GC collection
> cycles. If everything is freed, then there is no GC problem. not only this, but
> this is the only way GC and nogc code will interact with each others.

This does not address the stated need (by many programmers) to not even have to 
link in the GC code. A solution that falls short of this will be rejected. The 
rejections may not be technically well founded, but we're not in a good position 
to try to educate the masses on this. A solution that does not require linking 
to the GC sidesteps that problem.


> As long as a memory allocation has an owner the compiler can track, it can be
> freed explicitly, and, when it cannot, the compiler transfer ownership to the
> GC, which is illegal in @nogc code.
>
> Transfering the ownership to the unwind handler when doing:
>
> throw new FooException();
>
> Is not rocket science and doesn't need any new language addition.

There's also:

    auto e = someFunctionThatReturnsAnException();
    throw e;

where who owns it or how it was allocated is not clear at all.

Other issues that need attention are:

1. chaining exceptions
2. rethrowing


> Now onto to scope. Scope essentially means that you are going to use some object
> without taking ownership of it. Indeed, in case of catch(Exception e) the
> language has to transfers the ownership of the Exception to the GC, which is the
> thing that should be illegal (not throwing). catch(scope Exception e) would work
> both with GC owned and runtime owned exception, and, because the runtime know
> what's up, it can explicitly free the exception when it exit the catch block
> (there is already a runtime call for that), in the case it owns it.

'scope' is indeed a critical factor in making this work.


> It doesn't need any kind of throw new scope Exception, and was proposed,
> literally, years ago during discussion around DIP25 and alike.
>
> I urge you to reconsider the proposal that were made at the time. They solve all
> the problems you are discovering now, and more. And, while more complex that
> DIP25 alone, considering DIP25+DIP1000+this thing+the RC object thing, you are
> already in the zone where the "simple" approach is not so simple already.

I did some searching for this previous proposal discussion, but could not find 
it. Instead, I'll go by your description of it here.

I've written a more fleshed out proposal and started a new thread with it. Feel 
free to rip it to shreds!


More information about the Digitalmars-d mailing list