This article covers the basic of .NET framework exception handling and how to throw exceptions.
Introduction
In application/program number of things can go wrong and you can not imagine all the situations before hand during the application development, which results in application crash and related issue. In .NET framework there is rich support for handling such situations (Note: We are talking about the errors and not the logical bugs). Let’s examine how we can make use of .NET framework exception handling in our programs.
First let’s consider a simple method which does some mathematical calculations as follows
public double CurrencyConversion(double CurrentValue)
{
double ConvertedValue = CurrentValue/m_dFactor;
return ConvertedValue;
}
Now consider if the m_dFactor is zero and in that case we will have error ‘Divide by zero’, if we don’t handle this exception the application will crash/will behave in unpredictable manner.
Syntax for try-catch-finally block:
Now let’s see how we can handle this exception successfully and allow the application to continue/close gracefully.
public double CurrencyConversion(double CurrentValue)
{
double ConvertedValue = 0.0;
try
{
ConvertedValue = CurrentValue/m_dFactor;
}
catch (System.Exception excp)
{
MessageBox.Show(excp.Message);
}
finally
{
return ConvertedValue;
}
}
Now let’s take a closer look at the syntax and details of the above code. There are three types of code block that we can use to test, catch and handle runtime errors:
1. try block: This block tells the CLR that, this is the block of code where runtime exception might occur.
2. catch block: This is the block of code which gets executed of the specified type of exception occurs
3. finally block: This is the block of code which get executed whether exception had occurred or not. (Note: This is the block of code which is guaranteed to execute).
Now let’s take a look at the sequence of the event that will take us through the each code block.
1. Program enter try block. Each line of code is executed and if no error occurs then control is transferred to finally block.
2. If error occurs in try block then .NET framework create an object that represents the error occurred and transfers the execution control to the catch block. Note: we can have several catch blocks for a given single try block. Each of the catch block is examined and if a catch block is found that deals with the error object, the code within that block is executed and control is passed to finally block.
3. If catch block is not found that handles the error object then CRL passes the error object to the caller of the method. If no catch block is found the error is passed back until it reaches the Main() method. If Main method does not handle the exception then application crashes.
4. Finally block is executed. This gets executed irrespective of error occurrence. Also this will execute even if attempts to side-step the block are coded such as break, continue, return and goto statements in try/catch block.
Throwing Exceptions:
Sometime it’s necessary to cause an exception based on some condition that can be put through the normal handling routine. We can do this by using throw keyword as follows
throw exception object
Exception object: is an object of class representing exception. Note it must be derived from System.Exception class.
Summary
.NET framework provides a rich support for handling exception. The framework can be extended to create and throw custom exceptions based on the application requirements. (I will cover this in more details in part 2 of this article).
|
| Author: arunprasana 20 Feb 2005 | Member Level: Silver Points : 0 |
Hai,it's simple and super,easy to understand, plz give more example as possible
|
| Author: John 07 Mar 2006 | Member Level: Bronze Points : 0 |
Great site. This may be obvious, but can you only have one exception current at a time? Lets say at the data layer you get an exception and it follows its way back up the stack, but encounters a different exception. What then? Does the first one get lost? I believe I understand the idea of inner exceptions, but even so what if multiple exceptions were encoutered?
I ask this in part as I am wondering if you should be using exception handling for regular data validation errors you would present back to the user when they try do a Submit on a record add or update. In that case there could be multiple errors. So do you use exception handling for that, and maybe the Enterprise Libary Exception Handling Block, or is that too much as just keep errors and exceptions as seperate concepts?
|