@nogc and exceptions

[Johannes Pfau via Digitalmars-d]

Am Fri, 12 Sep 2014 12:47:44 +0000
schrieb "Vladimir Panteleev" <vladimir at thecybershadow.net>:

> On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
> > I can think of a couple of ways to go:
> 
> > 1) The most widely discussed path is to allocate exception 
> > instances statically, either in global memory or TLS. 
> > Currently, this has a few serious problems:
> 
> Another problem with this is that you'll need to change every 
> instance of "new FooException" to something else.
> 
> Here's a crazy idea that will never fly:
> 
> 1. Opt-in reference counting for classes. This needs 
> language/compiler support because currently we can't have both 
> reference counting and inheritance. For example, you could 
> annotate Throwable as @refcounted, and all descendants get it 
> automatically. The ref-counting overhead of exceptions should be 
> acceptable (even with locks), since exceptions should be 
> exceptional.
> 
> 2. Bring back the currently-deprecated new/delete operator 
> overloading.
> 
> If we could have reference-counted classes that are allocated on 
> the C heap, and keep the "new FooException" syntax, the problem 
> could be solved globally and transparently. Reference counting 
> implies that copies done using memcpy/unions/etc. will not be 
> tracked, but nobody does that with exception objects, right?

I think if we could avoid dynamic allocations for most exceptions
completely that'd be better. IIRC some people said that exceptions are
mainly slow because of memory allocation. So if we could avoid that,
there are more benefits.

I suggest looking at the C++ implementation. There's the throw-by-value
catch-by-reference idiom. C++ must store/copy this exception somewhere,
maybe they have a clever solution.

(We basically need some fixed-size per thread memory where we can store
the exception and stack trace info. But we need a fallback because of
exception chaining or big exceptions.)