Web Application Performance Design Inspection Questions - Exception Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Exception Management Issues



Poor client code validations

Round trips to servers and expensive calls.

Exceptions as a method of controlling regular application flow

Expensive compared to returning enumeration or Boolean values.

Throwing and catching too many exceptions

Increased inefficiency.

Catching exceptions unnecessarily

Adds to performance overhead and can conceal information unnecessarily.

To assess the efficiency of your approach to exception handling, review the following questions:

  • Do you use exceptions to control application flow?
  • Are exception handling boundaries well defined?
  • Do you use error codes?
  • Do you catch exceptions only when required?

Do You Use Exceptions to Control Application Flow?

You should not use exceptions to control the application flow because throwing exceptions is expensive. Some alternatives include the following:

Change the API so it communicates its success or failure by returning a bool value as shown in the following code.

  // BAD WAY
  // ... search for Product
  if ( dr.Read() ==0 ) // no record found, ask to create{
  //this is an example of throwing an unnecessary exception because
  //nothing has gone wrong and it is a perfectly acceptable situation
  throw( new Exception("User Account Not found"));
  // ... search for Product
  if ( dr.Read() ==0 ){ // no record found, ask to create
    return false;

Refactor your code to include validation logic to avoid exceptions instead of throwing exceptions.

More Information

For more information, see the following resources:

Are Exception Handling Boundaries Well Defined?

You should catch, wrap, and rethrow exceptions in predictable locations. Exception handling should be implemented using a common set of exception handling techniques per application layer. Well defined exception handling boundaries help to avoid redundancy and inconsistency in the way exceptions are caught and handled, and help maintain an appropriate level of abstraction of the error. Avoiding redundant exception handling helps application performance and can help simplify the instrumentation information an operator receives from the application.

It is common to set exception management boundaries around components that access external resources or services, and around facades that external systems or user interface logic may access.

Do You Use Error Codes?

Generally, you should avoid using method return codes to indicate error conditions. Instead, you should use structured exception handling. Using exceptions is much more expressive, results in more robust code, and is less prone to abuse than error codes as return values.

The common language runtime (CLR) internally uses exceptions even in the unmanaged portions of the engine. However, the performance overhead associated with exceptions should be factored into your decision. You can return a simple bool value to inform the caller of the result of the function call.

Do You Catch Exceptions Only When Required?

Catching exceptions and rethrowing them is expensive, and makes it harder to debug and identify the exact source code that was responsible for the exception. Do not catch exceptions unless you specifically want to record and log the exception details, or can retry a failed operation. If you do not do anything with the exception, it is likely that you end up rethrowing the same exception. Consider the following guidelines for catching exceptions:

  • You should not arbitrarily catch exceptions unless you can add some value. You should let the exception propagate up the call stack to a handler that can perform some appropriate processing.
  • Do not swallow any exceptions that you do not know how to handle. For example, do not swallow exceptions in your catch block as shown in the following code.

  catch(Exception e){
    //Do nothing

More Information

For more information about the questions and issues raised in this section, see .NET 2.0 Performance Guidelines - Exception Management.

Personal tools