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++!).