Truly @nogc Exceptions?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 20 15:52:15 UTC 2018


On Thu, Sep 20, 2018 at 11:25:27AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 9/20/18 11:06 AM, H. S. Teoh wrote:
[...]
> > IIRC, originally the stacktrace was also built at exception
> > construction time. But it was causing a major performance hit, so
> > eventually someone changed the code to construct it lazily (i.e.,
> > only when the catcher actually tries to look it up).
> > 
> > I think it makes sense to also make .msg lazy, if the exception
> > object is already carrying enough info to build the message when the
> > catcher asks for it. And if the catcher doesn't ask for it, we saved
> > an extra GC allocation (which is a plus even if we're not trying to
> > go @nogc).
> 
> Except we DON'T construct the stack trace string, even lazily. If you
> look at the code I posted, it's output directly to the output buffer
> (via the sink delegate), without ever having allocated.
> 
> I think we can do that for the message too (why not, it's all
> supported).  But either one (using GC at print time, or lazily
> outputting to buffer at print time) solves the biggest problem --
> being able to construct an exception without the GC.
[...]

Yeah, that's what I meant. :D  Well, for backward compatibility we could
still have .msg allocate and return a string, but we could provide an
overload / alternate member function that writes directly to a sink
instead.  Then we don't ever have to allocate unless the sink itself
does.


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom


More information about the Digitalmars-d mailing list