What is the drawback of the following "simple" @nogc exception creation technique?

import std;
void main()@nogc
{
    try{
        __gshared a = new Exception("help");
        scope b = a;
        throw b;
    }
    catch(Exception e){
        printf("caught");
    }
}

On Saturday, 14 August 2021 at 11:41:36 UTC, Tejas wrote:

import std;
void main()@nogc
{
    try{
        __gshared a = new Exception("help");
        scope b = a;
        throw b;
    }
    catch(Exception e){
        printf("caught");
    }
}

I mean, there has to be a gotcha, some weird multi-threading case where this catastrophically breaks and is therefore not recommended, right? Otherwise, why can't we just use this instead of fretting with DIP 1008? I even tried accessing the actual object in the code below, it didn't crash the program :D

import std;
void main()@nogc
{
    try{
        __gshared a = new Exception("help");
        scope b = a;
        throw b;
    }
    catch(Exception e){
        printf("caught\n");
        printf(cast(char*)e.msg);//new code
    }
}

On Saturday, 14 August 2021 at 13:24:22 UTC, Tejas wrote:

I don't think there are any gotchas here. The problem with this technique, is when your exceptions aren't just simple labels but also carry some additional data, say for example specific error type, and subject that, caused this. In such cases you can't have a gloablly shared instance. Let's say it's doable but has lot's of drawbacks.

Regards,
Alexandru.

On Saturday, 14 August 2021 at 15:28:36 UTC, Alexandru Ermicioi wrote:

Thank you.

If you're willing to help further, would you please tell me why there is a GC allocation in the code below that uses emplace? Will such code truly work if GC is never linked in the program?

import core.lifetime:emplace;
import core.stdc.stdlib:malloc;
int foo(int)@nogc
{
    auto mem = cast(Exception)malloc(__traits(classInstanceSize, Exception));
    auto memo = emplace!(Exception,string)(mem, "HOHOH");
    //scope b = a;
    throw memo;
}

void test() @nogc
{
    try
    {
        foo(1);
    }
    catch(Exception e)
    {
    }
}

void main()
{
    import std.stdio;
    import core.memory;
    auto stats1 = GC.stats();
    test();
    auto stats2 = GC.stats();
    writeln(stats1);
    writeln(stats2);
}

Output:
Stats(0, 0, 0)
Stats(1376, 1047200, 1360)

On Saturday, 14 August 2021 at 15:58:17 UTC, Tejas wrote:

https://run.dlang.io/is/XEc2WJ

onlineapp.d(26): Error: `@nogc` function `D main` cannot call non-@nogc function `core.memory.GC.stats`

Looks like GC.stats uses the GC.

On Saturday, 14 August 2021 at 23:14:51 UTC, Paul Backus wrote:

onlineapp.d(26): Error: `@nogc` function `D main` cannot call non-@nogc function `core.memory.GC.stats`

Then why is it (0,0,0) the first time it gets used?

I actually stole this from here and assumed the author knew what he was doing.

FWIW, using DRT-gcopt=verbose:2 gives grand total GC time as 0 so maybe there is something up with GC.stats only.

On Sunday, 15 August 2021 at 00:15:32 UTC, Ali Çehreli wrote:

I just want @nogc exceptions ;_;

Please tell me that the GC.stats thing I posted is irrelevant so that I can go back to using emplace.

I wanted to allocate a class on the heap without being forced to use templates... but I guess that simply isn't possible(I know I can use mixin, but that's even worse).

On Sunday, 15 August 2021 at 02:09:08 UTC, Tejas wrote:

In @nogc code, of course, like how for stack allocation there's simple scope c = new C(ctor args...), but to allocate on heap is auto c = heapAlloc!(A, ctor args...). I wanted to remove the !

On Sunday, 15 August 2021 at 02:09:08 UTC, Tejas wrote:

You can't really have @nogc allocated Exception without circumventing the type system. Personally I gave up on @nogc just because of how inconvenient it is.

Regarding the broader topic, at Sociomantic, we had pre-allocated Exception. After years working there, I grew to see the throw new Exception you see everywhere as an anti-pattern.

Exceptions aren't convenient to use. At the very least, we should have a way to print a formatted message, however nothing currently offers this.

A simple way to achieve this is the following:
https://github.com/bosagora/agora/blob/113c89bd63048a7b98b8e9a2a664bd0eb08ebc84/source/agora/common/Ensure.d

The gist of it is a statically allocated Exception (via module ctor) that is thrown by our ensure method. This is not pure unfortunately (because accessing a global mutable is not pure), and not @nogc (because snformat / formattedWrite aren't @nogc), but it doesn't allocate.

As Ali mentioned, having a single Exception in the program breaks Exception chaining. But Exception chaining is one of the lowest ROI feature of D: It took a lot of effort to implement correctly, and is barely, if at all, used. There have even been talks (involving Walter) of deprecating it.

If your goal is to never link in the GC, then you can barely use Phobos. If your goal is to never use the GC, I would say, why ? Using the GC for long-lived object and/or infrequent allocation doesn't hurt. GC collections are only triggered when you call new, so as long as you keep your critical path free of allocations, you're in the clear.

Another little piece of code you might find interesting: https://github.com/sociomantic-tsunami/ocean/blob/adb31c84baa2061d07aaa0cb7a7d14c3cc98309b/src/ocean/core/Test.d#L305-L340

This uses a built-in method (gc_stats) which predates GC.stats and doesn't work in D2, but I'm sure you'll easily figure out how to adapt it :)