On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] > 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),
I don't see why pre-allocated exceptions would be less informative. You can always modify the exception object before throwing it, after all. In fact, I've always wondered about the feasibility of a @nogc exception handling system where the exception is emplaced onto a fixed static buffer, so that no allocation (except at the start of the program) is actually necessary. Of course, chained exceptions throw(!) a monkey wrench into the works, but assuming we forego chained exceptions, wouldn't this work around the problem of being unable to allocate exceptions in @nogc code? (Albeit with its own limitations, obviously. But it would be better than being unable to use exceptions at all in @nogc code.) [...] > 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. [...] There's nothing about the 'throw' keyword that requires GC allocation. It's just that `throw new Exception(...)` has become a standard incantation. The exception object itself can, for example, be emplaced onto a static buffer as I propose above. T -- I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser
