Although our Signature Block program works pretty well now, there's no error checking or exception handling in it. We'll add some now. While we're seeing another example of exception handling, we'll also learn about another technique to handle errors: adding a log file to your program.
One reason a lot of exception handling might not be as necessary in the Signature Block program is that all the data comes from pre-existing files such as the SigBlockData.XML file. All the user has to do is select options and items from the ComboBox control.
But to see how exception handling works, let's create an error by simply deleting the last line from the XML file: </SigBlocks>. This closes the SigBlocks element and is necessary for a valid XML file. This is the kind of error that you might make creating the file manually.
When we save this incorrect file and run the program, it blows up with an InvalidOperationException error without doing anything. This isn't a very satisfactory user experience!
To solve this problem, let's first code a Try - Catch structure for the Subs in the SigBlock class that process XML: Load, New and ReLoad. After examining the detail available when the program crashes, it appears that the Message property does have something useful in it:
Message="An error occurred creating the form. See Exception.InnerException for details. The error is: Unexpected end of file has occurred. The following elements are not closed: SigBlocks. Line 31, position 1."
We first try simply coding a MessageBox provide better information to the user. Here's what that looks like:
Try
Using reader As XmlReader = ...
<the rest of the existing code here until>
End Using
Catch e As XmlException
MessageBox.Show(e.Message)
End Try
When this code has been added to both methods, at least the program doesn't crash anymore. But testing reveals that after the MessageBox displays the error a few times, the problem goes away entirely! Examining the code reveals that when the XML file is rewritten in the ReLoad Sub, Microsoft's objects make up for the problem and write the correct closing element node. This is a good example of how great system design can make software "self healing" and more robust.
Our second version substitutes a new technique, application logging, for the MessageBox.
Try
Using reader As XmlReader = ...
<the rest of the existing code here until>
End Using
Catch e As XmlException
My.Application.Log.WriteException(e, _
TraceEventType.Error, _
"Exception in ExceptionLogTest " & ".")
End Try
Application Error Logging
Application logging, like exception handling, can include a lot of sophistication for applications that need it. Much of what you might find in the official documentation tells you how to create logging for more demanding requirements. In our example, the logging is about as simple as it can be done. The WriteException method creates the log in a default location that can be overridden but is typically in the local user Application directory. For example:
C:\Users\Me\AppData\Roaming\aboutVisualBasic\SigBlock\1.0.0.0\SigBlock.log
You can find the location of the logfile by using another debugging tool, the Immediate window. Set a breakpoint in your program first (the statement won't work unless the program is in "Debug" mode). Then type ...
? My.Application.Log.DefaultFileLogWriter.FullLogFileName
The log file contains these records after a test run:
--------
Click here to display the illustration.
--------
In this case, some error checking was able to make the program self-correcting.
Currently, this is the last segment of the Visual Basic .NET 2010 Express tutorial. If you have suggestions for how it can be improved, send them to me at visualbasic@about.com.
