Performance of exception handling

[Steven Schveighoffer]

On Tue, 26 Apr 2011 14:26:00 -0400, Sean Kelly <sean at invisibleduck.org>  
wrote:

> On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
>
>> On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly <sean at invisibleduck.org>  
>> wrote:
>>
>>> Right now, traces are generated on throw. It should be possible to  
>>> generate them on catch instead. The performance would be the same  
>>> either way however. It would be nice to generate them lazily but I  
>>> don't think that's possible.

If it's possible to generate them on catch, couldn't you request trace  
generation while inside the catch block (or at the beginning of a catch  
block) if you intend to use it?

That is:

try
{
    ...
}
catch(Exception e)
{
    e.generateTrace(); // only allowed at the start of the catch block
    printException(e); // if you haven't generated the trace by now, it's  
gone.
}

You'd need compiler help for this probably.  But I agree with the OP, 99%  
of the time you are catching exceptions you do not need the trace.

>> Interesting enough, it is already done lazily (in toString(), which I  
>> believe should also cache result when it's called first time), but it  
>> can be improved a bit.
>
> The readable version is generated in toString, but the actual trace  
> occurs on throw.  This pretty much requires a memory allocation to store  
> the trace info, which is one cause for the performance hit.

I can't help but think that using the GC may be overkill here.  At the  
very least, you can use C malloc which is usually much faster.  The  
exception should encapsulate the memory allocation and deallocation  
completely.

-Steve