Error Handling and Debugging

After years of primitive error handling, both Visual Basic and Visual FoxPro have finally acquired real error-handling capabilities with the TRY...CATCH block. And Visual Basic .NET actually has more debugging features than does FoxPro.

TRY...CATCH

The syntax for TRY...CATCH is slightly different for Visual Basic .NET than for Visual FoxPro.

Here's the syntax in Visual FoxPro:

 TRY       Code here Catch To oEx WHEN ERROR() = 1234       What to do for this error Catch To oEx WHEN ERROR() = 4321       What to do for this error Catch To oEx       What to do for all other errors Finally       Do this whether there was an error or not ENDTRY 

At a minimum, you can print out the error details:

 Msg = oEx.Message + CHR(13)+oEx.Details + CHR(13)+oEx.LineContents MessageBox ( Msg, 32, "Error" ) 

And this is the syntax in Visual Basic .NET:

 Try       Code here Catch oEx as ExceptionType1  (of about 60 exception types)       Code to handle ExceptionType1 Catch oEx as ExceptionType2  (of about 60 exception types)       Code to handle ExceptionType2 Catch oEx as Exception       Code to handle all other Exceptions Finally       Do this under all circumstances END Try 

Similarly, you can print out oEx.Message + CHR(13)+oEx.Source to see the error message and offending code.

Visual Basic does have additional language elements ( Error , Raise , GetException , Err , On Error , and Resume ), but Try...Catch is a lot better.

Error trapping is meant to allow graceful handling of unavoidable errors in the program, due to device unavailability (CD-ROM, printers, floppy drives ), incorrect input that can't be prevented, and other errors that are the result of normal program operation. Error trapping is not meant to be used to catch errors in program logic. Still, it's better than letting users see messages from the FoxPro or the .NET IDE.

In the code that appears in this book, we have left out error trapping in most code samples. That doesn't mean that we recommend leaving it out of your code. In fact, Try...Catch blocks are an excellent idea, and should be used in every case where a user or system error is possible. (It can even be helpful in finding your own coding errors during debugging, although that's not the purpose of Try...Catch.) But we've decided to focus on the main purpose of each code fragment, and adding error trapping to a single line of code tends to make the code harder to read. So with regard to error trapping, do as I say, not as I do.

Debugging

Debugging support is awesome in both languages. In FoxPro, you can either toggle a breakpoint by clicking in the selection margin of the code at the point where you want the code to break, or you can insert a SET STEP ON command. In Visual Basic .NET, you can either toggle a breakpoint by clicking in the selection margin of the code at the point where you want the code to break, or you can insert a Debugger.Break command.

FoxPro Debugging Aids

At this point FoxPro provides you with five windows :

• Trace (to step through the code)

• Locals (all variables and objects)

• Watch (type in the names of the variables to inspect)

• Call Stack ( A called B called C , and so on)

• Debug Output ( Debug.print output goes here)

In addition, you can add assertions to your code. Assertions are statements that only execute if they evaluate to False , and only if you SET ASSERTS ON . You'll get a little dialog window that asks if you want to debug. This permits bracketing of debugging code in a way that it can be turned on and off with a single command in the command window.

Visual Basic .NET Debugging Aids

In Visual Basic .NET, Debugger.Break (or a breakpoint entered in the Selection Margin of the code window) gives you a vast array of debugging windows:

• Modules

• Threads

• Call Stack

• Me

• Command window

• Locals

• Autos

• Watch (four of them!)

• Running Documents

• Breakpoints

Each of these windows gives you some of the information about your program's state at the breakpoint. You can either go to the command window in Immediate mode and print the contents of individual Variables and object properties, type the name of the object in a watch window, or look in the Locals window to see if it's there already.

It's clear that both languages offer excellent error trapping and debugging capabilities.