Visual Basic —

Dealing with Errors

In terms of error handling you have two choices: don't, or use On Error Resume Next. You cannot use line numbers or labels in your code, so On Error GoTo would not work anyway. If you've been reading the various error handling articles produced by both Peet Morris and me, you are no doubt aware of the broad strategy of inserting generic catch-all error handling code throughout your application and then writing more specific handlers for anticipated errors. With the reduced error handling capabilities, a good scheme for Windows CE applications is to omit the generic handlers and just code for anticipated errors. This is because the Windows CE error handling mechanism has also been changed. If an unhandled error occurs, Visual Basic will display the default error message box; unlike other versions of Visual Basic, however, the program will not be terminated. Instead, the call stack is cleared and your application returns to an idle state (the state you were in before the last event was invoked). Beware! Your application is now in a stable state, not a known state. If you have written some data or manipulated some variables before the error occurred, it is possible that your application will actually be in an invalid state. The following pseudocode illustrates this:

  Private Sub PurchaseItem_Click()
      aShoppingBasket = GetShoppingBasketList
      aCustomerAcct = GetCustomerAccount
      aShipList = GetShipList
      For Each Item In aShoppingBasket
          If aCustomerAcct(CustomerBalance) _ Item(Price) > 0 Then
              AddToShipList Item(ItemCode), aCustomerAcct(CustomerNumber)
             *** ERROR ****
              DeductFromCustomer Item(ItemPrice), _
                                 aCustomerAcct(CustomerNumber)
          End If
      Next
  End Sub

In this example the unhandled error causes the procedure to exit, and code after the error will not be executed. If the For Each loop had already performed some iterations before the error, you would effectively have a situation where some of the orders had been placed, but not all of them. The shopping basket data would still contain both processed and unprocessed orders, which means that if the procedure were invoked again for the same customer, you would have doubled some of the orders. You can prevent errors such as this by changing the design of your program. For example, in the code above, a better idea would be to remove the item from the shopping basket immediately after an individual order has been placed, and then write a specific error handler around the transaction.

The default error message box displayed by Windows CE is shown in Figure 5-14. The error message varies depending on where the error has occurred; in this example, the error has occurred after the application's form has loaded. Errors in the Form_Load event procedure are a little harder to trap. This is because the Form_Load event procedure executes before the debugger is loaded. You cannot, therefore, set a breakpoint to trap the error. Remember that Visual Basic debugging is not integrated with the Windows CE environment, so the Break options have no effect. An error that occurs while running your application does not cause the program to break into debug mode. The only way to trap an error is to set a breakpoint in the debugger and then step through the code until the error is reached.

Figure 5-14 An unhandled error message from Visual Basic for Windows CE

The Pontoon application does not contain any error handlers. At design time and during coding, I evaluated the possibility of an error occurring. In this application there are no places where I can anticipate an error, so it would be a waste to code error handlers everywhere just in case. Remember that using On Error Resume Next requires lots of code to implement correctly because you need to check for an error after every line where an error could possibly occur. Another disadvantage is that because you cannot have line labels, you will effectively end up having deeply-nested conditionals. When determining your error handling requirements, it is obviously important to consider how critical the application is. If the Pontoon game has an error, the consequences are not severe. The Err object is available for diagnosing errors, although the Erl property is not present for obvious reasons.

If these limitations seem a little restrictive, I'll remind you again of the types of applications you will be creating at this stage. As Microsoft's goal to allow development for any platform in Visual Basic gets closer to reality and the hardware's capacity grows, I expect the error handling capabilities will grow to comparable levels with that of other versions of Visual Basic (or maybe even C++!).