When to create exception objects

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


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?


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 (5)

  1. Akshay Kumar says:

    When you say "don’t throw expensive exceptions in any scenario which you expect to have decent perf" what does that mean.

    Are exceptions created from ApplicationBaseException expensive ?

    And why is throwing exceptions expensive?

    Where is the line , what is the criteria that determines whether to throw exceptions or not.

    If you throw some light that will be very helpful.



  2. Rico Mariani says:

    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

  3. Nicholas Allen says:

    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.

  4. David Levine says:

    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.


  5. Here’s an article under Jon’s Homepage that was just brought to my attention.  It’s an interesting…

Skip to main content