On Tuesday, September 13, 2016 14:43:09 Walter Bright via Digitalmars-d wrote: > Case in point, exceptions. Currently exceptions are fairly wedded to being > GC allocated. Some people have opined that this is a major problem, and it > is if the app is throwing a lot of exceptions. But exceptions should be > exceptional. > > There is still a place for GC, even in a high performance app. The > all-or-nothing approach to using the GC is as wrong as any programming > methodology is.
The big problem with exceptions being allocated by the GC isn't really the GC but @nogc. Obviously, a program that does not use the GC at all can't allocate an exception with the GC, but in general, I would fully expect that even a program that allows the GC but uses it minimally would have no problem with the garbage created by exceptions precisely because they should be rare. But none of the code that's marked @nogc can throw an exception unless you're either dealing with pre-allocated exceptions (in which case, they're less informative), or you are _very_ careful with how you write that code so that you can get away with malloc-ing the exception (but that approach won't work in the general case unless you don't care about leaking the memory from the exception, since most code would assume that the exception was allocated by the GC and wouldn't know how to free it). So, @nogc code is going to have a tendency to not use exceptions just because exceptions don't work well without the GC. And those who want to use exceptions and are willing to have their code not be @nogc will forgo @nogc even when the code could have been @nogc otherwise. So, I really think that we need to find a way to make it so that exceptions aren't GC allocated normally anymore - or at least have a way to reasonably and easily not be GC allocated - but the problem is @nogc, not the actual memory management or its cost. - Jonathan M Davis
