Share via

When to create exception objects

  • Article

I got this question today, thought I'd share my answer here:

Q:

People are creating and throwing an exception at the same place, usually when a problem occurred.

Does it hurt if someone creates an exception in a static construction, then throw it later?

A:

We do this in the runtime for out of memory exceptions and some other cases. 
 
Generally speaking we think it is good practice to have a helper method that creates the exception to facilitate sharing of the code if nothing else.
 
Creating exceptions in advance is often problematic because they have instance data which may not be applicable to describe the specific problem.  I would say that if you have any exceptions for which the allocation of the exception is something you're concerned about you have made a giant mistake in the first place and no amount of precreation will rescue you.
 
So, general advice:

  • don't throw expensive exceptions in any scenario which you expect to have decent perf
  • use a helper method to create and throw the exception (by ID for instance)
  • don't have a lot of statically created exceptions because instance data makes them less sharable than first appears

But whatever you do, don't make a decision based on (just) anecdotal wisdom like this:  rather use these ideas to suggest experiments that you should conduct and measure to get the right answer.

More advice on throwing exceptions can be found here.

Comments

  • Anonymous
    July 12, 2004
    The comment has been removed
  • Anonymous
    July 12, 2004
    I wrote a much longer article on those topics previously. Have a look at http://blogs.msdn.com/ricom/archive/2003/12/19/44697.aspx
  • Anonymous
    July 13, 2004
    In the Java world, 80-90% of the cost of using exceptions is filling in the stack trace during initialization. For this reason there are a lot of bad performance books that recommend creating a static exception and throwing it multiple times to "make exceptions cheap". Usually this is only an issue when someone is using exceptions in the wrong way to begin with.
  • Anonymous
    July 13, 2004
    There's a cost associated with simply defining a try-catch or try-finally block but except in the most performance sensitive scenarios the cost is so minimal it isn't worth bothering about.

    Most of the costs are associated with throwing the exception and capturing the stack trace. But even if you ignore capturing the stack trace the exception still round-trips through the kernel (i.e. a ring transition)and has substantial interaction with the underlying OS (and attached debuggers) as it searches for a handler. A side effect will usually be to flush the processor cache. Chris Brumme wrote extensively about this.

    The cost of simply allocating an exception object is minimal since it does not capture the stack at that time - it just allocates memory and sets a few fields. However I don't see much reason to preallocate all your exception objects in static constructors. For one thing it doesn't sound thread safe (what if two or more threads all try to throw the same exception object at the same time?) For another, the cost of the actual throw is so much higher then allocating the memory for the exception object that it's likely to unnoticable. As you point out I'd do it for ensuring an object is available at times when the system may be unstable (low memory, etc), but other then that I don't see much upside in it.

    FWIW
  • Anonymous
    September 14, 2006
    Here's an article under Jon's Homepage that was just brought to my attention.  It's an interesting...