For programmers, exceptions—that's just a fancy name for run-time errors—are a fact of life. Good programming practices can minimize exceptions, but it is impossible to prevent them altogether. Many of the causes, such as network errors or incorrectly set file permissions, are beyond the programmer's control. This excerpt from Informit explains how to filter the Catch statement to handle exceptions.
I'll use Visual Basic, in this article, but the same principles and techniques apply to C# as well.
The .Net framework implements structured exception handling. The term structured means that the code has the potential to cause an exception. Plus, the code to handle the exception is organized in structured blocks. You use the Try...Catch...End Try statement for this purpose.
The ability to filter the Catch statement is an essential part of .Net's structured exception handling. If there is no filter—or, to be more precise, there is a filter that matches all exceptions—the code in the Catch block is executed for any and all exceptions that are thrown. Such a Catch block would be written like this:
Catch ex As Exception
Within the Catch block, the object ex, an instance of the System.Exception class, will contain information about the exception. You can use any legal variable name here, although ex or e is traditional. To filter for specific exceptions, you would write the Catch statement like this:
Catch ex As ExceptionType
replacing ExceptionType with the name of the specific exception class to be caught. The .Net framework defines a hierarchy of several dozen exception classes, all derived from System.Exception, with each individual exception class encompassing related exceptions. For example, all file-related exceptions are subsumed under IoException, but for more specific control you can catch file loading exceptions with FileLoadException and FileNotFoundException. You'll find a complete diagram of the exception hierarchy in the Visual Studio documentation.
The filtering capability lets you write Catch blocks to deal with specific exceptions. This makes perfect sense, because the message to the user and the program's response will differ, depending on the type of exception. Simply create a separate Catch block for each condition. It is also common practice to include a final Catch block to deal with any exceptions that fall through the preceding Catch filters. Here's an example:
Catch ex As FileNotFoundException
' Code here to respond to a "File Not Found" exception.
Catch ex As FileLoadException
' Code here to respond to a "File Load" exception.
Catch ex As Exception
' Code here to respond to any exceptions not caught by previous Catch statements.
The Catch keyword, by itself, will catch any exception, just like Catch ex As Exception. The disadvantage is that you will not have an Exception object in that block to provide information about the exception and its cause.
Read the rest of this Informit article for more filtering techniques as well as ways to respond to exceptions.
