OSNews

If you come are a COM background, you would know that there is not one way to generate and handle exceptions, which to me as a consumer and creator of components was a very painful task to handle. Just the different ways to deal with exceptions between c++ and VB would be enough to drive a sane person up the wall. Thankfully, in .NET provides a better approach to resolve the whole mess. The .NET Common Language Runtime (CLR) provides a uniform way to notify the different applications of an exception, even if they are written in different languages.

Understanding Exceptions
Most programmers who I have worked with that are either new to programming or do not come from an object oriented background (such as c++. Java, etc.) have a poor understanding of what an exception is. An exception is the violation of a contained assumption. E.g. your code tried to access a file that it assumes to be present, but if is not then an exception would be thrown. However if you application first checked to see if the file was present before trying to access it, then that scenario may not throw an exception.

It is important to understand is that an exception is not necessarily an error. The context in which an exception occurs within the application governs if it is an error or not.

All Exception classes should derive from the Exception base class. The exceptions can be created either by the runtime or programmatically by your application. All exceptions generated by the runtime are derived from the SystemException class (which ultimately derive from the Exception class). Your application’s custom exceptions should derive from the ApplicationException class which also derives from the Exception base class.
try
{
     //try and do something here...
}
catch (SomeExeption ex)
{
     //Handle the exception and take appropriate action
}
finally
{
     //This code will *always* run irrespective if you have
     //an exception or not. Usually this is some clean up of
     //some sort though.
}


The try block has the code that could throw an exception and the catch block catches it. You can have more than one catch block and should be ordered from the most specific to the most generic in ascending order. The first catch filter that matches is the one that “catches” the exception, so it is important to keep the order in mind.

Exceptions vs. Errors
Exceptions are very expensive operation and should not be taken lightly (as most developers do). As a developer you need to understand the distinction between an exception and a error and when should you use one over the other. In general, you should throw an exception only when it violates some condition outside of your code.

Take the example where in your application you have an Update Profile screen (or page), where the user can update their profile with the user’s First and Last Name as required fields. In this scenario, throwing an exception when the user forgets to enter one of the required fields would not be a good practice, as this should be an expected condition for the application and should be handled via the normal flow of execution. However, if the database that the application connects with, to update the profile is not available is an Exception. Many developers get lazy here and treat everything as an exception.

The following example uses a if statement to check whether a connection is closed. You can use this method instead of throwing an exception if the connection is not closed.
if(conn.State != ConnectionState.Closed)
     conn.Close();

In the following example, an exception is thrown if the connection is not closed.
try {
     conn.Close();
}
catch(InvalidOperationException ex) {
     //Do something with the error or ignore it.
}


The method you choose depends on how often you expect the event to occur. If the event is truly exceptional and is an error (such as an unexpected end-of-file), using exception handling is better because less code is executed in the normal case. If the event happens routinely, using the programmatic method to check for errors is better. In this case, if an exception occurs, the exception will take longer to handle.

1. "Exception Management in .NET, Page 1/3"
2. "Exception Management in .NET, Page 2/3"
3. "Exception Management in .NET, Page 3/3"