Exceptions in @nogc code

Eugene Wissner via Digitalmars-d digitalmars-d at puremagic.com
Sat Apr 1 08:27:58 PDT 2017


On Saturday, 1 April 2017 at 14:54:21 UTC, deadalnix wrote:
> I'll repeat myself, even if I don't believe it'll be listened 
> to at this point.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Things are unfolding exactly as predicted at the time. Ad hoc 
> solutions to various problems are proposed one by one and the 
> overall complexity is growing much larger than initially 
> proposed solutions.

I also want to add that the syntax is ugly. A lot of work is 
being done on "scope" currently, but I don't understand why 
"scope" should appear now in every line of code: scope 
parameters, scope exceptions... How do I decide if I should use 
"new Exception" or "throw new scope Exception"? If it is a 
migration path and everyone should migrate to "new scope 
Exception", then "throw new scope Exception" is still one keyword 
longer than the simple "throw new Exception". Imho it would be 
better to change the way exceptions are allocated instead of 
making a complex language even more complex.


More information about the Digitalmars-d mailing list