Drawbacks of exceptions being globally allocated

Mathias LANG geod24 at gmail.com
Sun Aug 15 03:45:07 UTC 2021


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 :)


More information about the Digitalmars-d-learn mailing list