Errors are possible in every program, no matter how perfect. Handling these errors, so the people who use your program won't have to deal with a runtime crash, is something that every programmer should add before the program is considered to be "finished".
The technology to handle errors has been added to VB.NET using a model that has been used by C programmers for decades. So these methods have been tested and improved for you. The technology usually goes by the name "Try-Catch" because those are the keywords that have to be part of the code. (Also called "Try-Catch-Finally" but the Finally block is optional.) Another name for this error processing is "structured exception handling" because, as we will see, errors can be handled by a whole structure of program blocks, not just one routine. (Many people even use a TLA - Three Letter Acronym - SEH for .NET error processing.)
.NET allows the same old style of exception handling that was used in previous versions of Visual Basic and this is generally called "unstructured" error processing today. This article doesn't explain unstructured handling because it's inferior to the newer .NET way. (The About Visual Basic VB.NET Express tutorial discusses unstructured error processing in the segment, "Errors: Preventing and Handling Them".
Just to be more clear, there's a difference between an "Exception" and an "error". An error is when something goes wrong and it's not a technical term. An Exception is a .Net object that is created by the runtime and passed to your program code when most errors occur. That's why the technique is correctly called, "Structured Exception Handling" and not error handling. But there are some errors ... for example if power to the computer is lost ... that just can't be handled. Errors relating to security also require more specialized code.
You shouldn't overdo exception processing by trying to use it for expected or normal events. For example, end-of-file processing. Exception processing is relatively inefficient and should only be used to handle unexpected problems.
Since Exceptions are actually software objects, they're organized in .NET just like other objects. To help you write code customized for the types of errors you think should be handled in your program, .NET provides hundreds of different type of exceptions. The illustration shows just three example objects, AccessViolationException, ArithmeticException, and FormatException, of these hundreds that inherit from the parent Exception object.
--------
Click Here to display the illustration
--------
"Structured Exception Handling" relies on the Try-Catch structure. The basic idea uses code like this:
Try
' Section of code where
' a particular type of
' exception might be thrown.
Catch ex As Exception
' Code to handle the
' exception thrown.
End Try
A Finally block, coded just before the End Try statement, can also be used. A Finally block will be executed after all Catch blocks whether the exception is handled or not. In many cases, a Finally block isn't useful because your code handles completely different things in the Try and Catch blocks and there isn't anything that will always be done whenever an exception of any kind occurs. But it can be a good place to release resources and close files if necessary.
Notice that the Try block contains the statements where an exception might occur. This is the key to coding exception handling. You have to anticipate where a problem might happen and then place that code inside a Try block. Then, based on the errors that might happen, you code Catch blocks to do whatever can be done to recover from errors. In the example below, the error that is anticipated is an incorrect file name. The recovery is to reenter the name.
In the case of file processing, just a few of the possible exceptions that might occur include:
- DirectoryNotFoundException
- DriveNotFoundException
- EndOfStreamException
- FileLoadException
- FileNotFoundException
... and even something like ...
- PathTooLongException
On the next page, we dive into some code and see how it really works.