.NET Exceptions

Article Index
.NET Exceptions
Page 2

Page 2 of 2

The Try Block

The try block can be defined as code that can possibly raise exceptions—for instance mathematical calculations, Database Connection and queries, Writing to a log file, or reading from a file. The Try block, the Catch block and the Finally… function together to handle the exception.

The Catch Block

A single Try block can have more than one catch block. If an error occurs during execution of any of the code in this section, Visual Basic examines each Catch statement within the Try...Catch...Finally until it finds one whose condition matches that error. If one is found, control transfers to the first line of code in the Catch block. If no matching Catch statement is found, the search proceeds to the Catch statements of the outer Try...Catch...Finally block that contains the block in which the exception occurred. This process continues through the entire stack until a matching Catch block is found in the current procedure. If none is found, an error is produced. General exception handler to catch any other exceptions can also be added.

The Throw Statement

You can also explicitly use a throw statement to throw or re-throw an exception. Let us see an example for this now. Any exception that prevents further flow of information is automatically thrown which are handled in the try catch finally blocks. However user generated exceptions are used to be thrown in this fashion. You need do explicitly use throw statement to throw these exceptions that will be handled by the try catch finally blocks. For this purpose you need to create a new object based on the ApplicationException Object.

Click here for Sample Code

The Finally Block

The code in the Finally block is always executed at the end, just before the error handling block loses scope, irrespective of whether the code in Catch blocks has executed or not. This block is normally used to clean up the code.

Salient points about error handling:

Local variables from a Try block are not available in a Catch block because they are separate blocks. If you want to use a variable in more than one block, declare the variable outside the Try...Catch...Finally structure.
If errors occur that the programmer has not handled, Visual Studio for Applications simply provides its normal error message to a user, as if there was no error handling.
The Try block contains code where an error can occur, while the Catch block contains code to handle any error that does occur. If an error occurs in the Try block, program control is passed to the appropriate Catch statement for disposition. The exception argument is an instance of the Exception class or an instance of a class that derives from the Exception class corresponding to the error that occurred in the Try block. The Exception class instance contains information about the error including, among other things, its number and message.
In partial trust situations, such as an application hosted on a network share, Try...Catch...Finally will not catch security exceptions that occur before the method containing the call is invoked.

Custom Exceptions

The exceptions that are raised can be classified in to two categories.

Managing Unhandled Exceptions

Microsoft recommends that programmers should handle unhandled exceptions in a single error handler. They further state that the user should be given the option of continuing with the program or exiting the program when such an error is encountered. Consider a simple Windows Forms application containing a single form with two buttons and a text box. The Add button just adds text to the text box. The Remove button clears it. Normally this would be caught by a try-catch block. By writing an unhandled exception delegate, this can be dispensed with. The signature for the delegate looks like this.

Click here for Sample Code

Unhandled exceptions events can be moved into an assembly wide class so that it can be accessed by other forms. The unhandled exception generates an AbortIgnoreRetry dialog box giving the full description of the error.