In the Line of Fire -- Ramblings of the incoherent mind

Exception handling and performance

The vanila try- catch statement:

try
{

// Execute the code for SQL
}

Catch(Exception Ex)
{

// Handle the exception.
}

In the above example the try catch encapsulates a piece of code executing some DB operations.
In case there is an exception thrown in the try block code the exception will be smartly catched in the catch block and can be processed and handled.

Catch working.

A Catch block is used as a catcher of exceptions. i.e A catch block will catch the exception or any child exceptions that are derived from the class.

try

{

// Execute the code
}

Catch(ArgumentException Ex)
{

// Handle the exception.
}

In the above case any exceptions from the ArgumentException class will be caught in the catch block this will also include any child exceptions of the ArgumentException such as ArgumentOutOfRangeException, ArgumentNullException etc. As these exception classes are derived from the parent class ArgumentException (Remember .NET classes have loads of base classes :) )

Now that its caught what to do?

A Million dollar question!!! In code reviews have seen developers writing a try catch block and catching the exceptions and doing nothing with it. Wake up!!!!!! guys an exception is a exceptional flow of the code.. ie the moment it comes in the exception block it means this wasn't the expected flow so obviously we cant let it go silently unnoticed.

Of course we don't navigate it back to the user , but we do need to log it, process it, pass it back to the calling method with more info etc so that the developer is aware of the exceptions that occurred.

When i say Pass it back to the calling method a qts arises in our mind.. if we have to pass it to the calling function why in the name of God do we need to catch it as if we dont catch it it will automatically get thrown back to the calling method!!!!!!.

Thats true completely true, but as a developer we need to understand the exact location of error, maybe we want to add more custom information to the exception and then pass it back to the calling method.

Lets take an example of a utility class you have written for processing some data, now since this is a class which will be providing service to the classes calling on it.It will have to give out details of the exception if any that it will face in the operations..

try

{
// Open file
// Process data
// Send confirmation mail

}Catch(Exception Ex)
{

Logger.WriteLog("Exception: Method: ProcessData: Parameters: A = 4, b= "ABC");
Throw new Exception("Error occured in processing data MethodXYZ with parameters a = 4, b ="ABC", ex);
}

The above try catch block will not only handle the exception thrown but also log it into the custom logger and then send a customized exception with the details as well as the stack trace for the exception.

Such detailed exception/debuggin output will not only help the developer pinpoint the exception source but also provide him the details of the object when the exception occured.



P.S Its not a good idea to create new exception class objects and send the existing exception through it as it has some performance issues so choose carefully.

Multiple Catch

In the above scenario it would have been better to even drill down to the exact exception type as we have 3 different piece of code

1) File operation
2) Data Processing
3) Email functionality

* Ideally all these 3 functionality should be in their separate methods for maintainability but for the purpose of this example had to club them together in 1 method.

try

{
// Open file
// Process data
// Send confirmation mail

}
Catch(IOExecption Ex)
{
// Perform catch handling for File input /output exceptions
}
Catch(SQLException Ex)
{
// Perform catch handling for DB exceptions
}
Catch(Exception Ex)
{
// Perform catch handling for general exceptions
}

Order of catch blocks and the importance behind it.

We can very well have multiple catch blocks to handle specific exceptions and process them in specific ways, but in such a case such as the above the order of catch blocks holds lot of importance in the way the catch blocks will be functioning.

Care needs to be taken to see that the most specific catch blocks should be on top of the generic exception catch blocks. inshort the derived exception class catch should be on top of the parent exception class.
Please Note: Exception is the parent of all the other exception classes, hence the catch block for exception should be the last

Before we move on to the last part of exception handling need to mention the last catch block which will take care of any exception

try
{
// code
}
Catch
{
}

Why did .NET give this class? when we already have Exception which is the parent class for all exceptions?? Well the answer is simple Exception class is the parent class for all the exceptions that are thrown through managed code or rather .NET code. what about the code which might throw exception ie not written in .NET maybe a COM component, C++, code ? In such a case we can use the above catch block.This block however due to lack of the exception class/object will not provide us with any information on the exception.Its only useful for making sure no exceptions get through.

Finally Block

The last part of try catch is the finally. It should be like a inseparable trio try-catch-finally block.
As we have seen till now incase there is any error the code execution halts at the error code statement and the execution gets thrown into the catch block.

Now incase we had opened a Database connection / File / etc and inbetween the processing of the connection the exception occurs the execution will be thrown to the exception block and in turn the code for closing of the statements wont be executed and the connections will remain open.

To take care of such situations we have a Finally block and as the name suggets this block is executed finally ie after all the above code in try or catch block gets executed.

The finally block is executed:

• Incase the code gets through the try block without any errors


• Incase the code falls through the Catch block because of some exceptions.


• Incase of any flow followed by the code.So the best bet is to put such code in finally block which has to be executed irrespective of the flow of code.
  

  
  

  try

  
  {
  
  1) Open Database Connection
  2) Retrieve Records
  3) Process data <<------ Exception gets thrown at this point.
  4) Update records back to DataBase
  5) Close Database Connection
  
  }
  Catch(SQLException Ex)
  {
  
  Logger.WriteLog("Exception: Method: ProcessData: Parameters: A = 4, b= "ABC");
  Throw new Exception("Error occured in processing data MethodXYZ with parameters a = 4, b ="ABC", ex);
  }
  Finally
  {
  If (Connection is Open)
  {
  Close Connection
  }
  }

  
  In the above scenario we have opened a connection in Point # 1 and while processing data i.e Point # 3 the exception gets thrown.In such a case the other statement below ie Point # 4 & #5 will never get executed as the control will be thrown to the catch block and then out of the method. This will lead to open connection.To take care of such situations instead of writing the close connection code in the Try block we should write the same in the Finally block as this block will get executed irrespective of whther there is an exception or not.

   UPDATE: plz check this post related to exception being raised due to using Response.Redirect
           in a try catch block

Copyright © Shounak Pandit