On exceptions in D

[Jakob Ovrum]

On Tuesday, 11 February 2014 at 17:03:13 UTC, Dmitry Olshansky 
wrote:
> 10-Feb-2014 02:25, Jakob Ovrum пишет:
>> On Sunday, 9 February 2014 at 20:26:20 UTC, Dmitry Olshansky 
>> wrote:
>>> I'm saying that basically classes imply infinite lifetime 
>>> model. Then
>>> you may work extra hard and do things like emplace and manual 
>>> allocation.
>>
>> Infinite lifetime is also only with `new`. The "extra work" 
>> with emplace
>> and manual allocation is the domain of library code (e.g. `C c 
>> =
>> alloc!C(ctorArgs);`).
>
> I thought of this for a while and I think lazly dynamic 
> allocation is still better. First things first - there is still 
> lazy initialization both ways.
>
> The only potential gain of statically allocating memory here is 
> on the first exception being thrown, which doesn't gain 
> anything for our prime case of "many exceptions".

I was thinking of disadvantages such as GC heap fragmentation, 
accidentally causing collection cycles in response-critical code 
(though minor when an exception is thrown, for obvious reasons), 
and being usable for people have disabled the `new` operator in a 
custom GC-free druntime.

> Lastly if the said exception is never thrown, static allocation 
> would waste more memory of each thread (TLS). This is 
> especially true for cases where not every thread runs the same 
> code (which is not a small part of the landscape).

Yes, this is a killer point. I was saying the exception is only 
allocated if the template is actually instantiated, and if it is, 
it's safe to say it's used - but by no means by all threads!

So yeah, dynamic allocation it is.

> I'm thinking that I probably should compile this discussion to 
> some
implementable enhancement request for Phobos.

Are you talking about `emplace` for nested classes and such?

> `cachedException` or some such sounds like something suitable 
> for std.exception.
>
> Thoughts?

I like it. I also like the name; I couldn't think of a good name 
myself... though it does cause some redundancy on use:

throw cachedException!MyException(args...);

It still needs some changes in druntime/object.d though, to 
prevent infinite loops on exception chaining.