On Sunday, 15 August 2021 at 02:09:08 UTC, Tejas wrote:
On Sunday, 15 August 2021 at 00:15:32 UTC, Ali Çehreli wrote:
On 8/14/21 4:41 AM, Tejas wrote:
> [...]
exception
> [...]
So, there would be many exception objects one for each place
that an exception can be thrown. Functions like enforce()
would have to take a reference to the exception object that is
associated with that local scope.
[...]
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).
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 :)
