Error Handling and Testing

[Previous] [Next]

Before examining how you can use ADO to determine why your update attempt failed, let's briefly discuss error handling and testing.

Error Handling in General

Thorough error handling is the key to dealing with update problems, but while I have a lot of experience programming in Microsoft Visual Basic, I don't spend my days writing components or applications that need to handle a wide variety of potential problems. The sample code used in this chapter utilizes simplistic error handling. Writing effective, complex error-handling routines is beyond the scope of this book.

I strongly recommend that you pick up a book on programming your language of choice to learn the best way to write error-handling routines. For Visual Basic programmers, I definitely recommend Advanced Microsoft Visual Basic 6.0, Second Edition, by The Mandelbrot Set (International) Limited [Microsoft Press, 1998], specifically the chapter titled "On Error GoTo Hell."

Even though I don't need to write a lot of error-handling routines, I've learned this much so far: You simply can't write a generic routine to handle all errors. You must determine what particular problems your application might need to handle and write routines to trap these errors. If you can determine the cause of the error, you should handle it appropriately and allow the user to continue using the application. Furthermore, your application should fail as elegantly as possible when you receive an unexpected error.

Becoming Your Own Worst User

The best way to see how your code will react to a particular problem is to cause that problem and watch what happens. Figure out how to use the interactive debugging mode of your programming language of choice, or write an error-logging routine to log unhandled errors. Then cause the problem you want to handle, determine what code you need to add to trap for that error, and handle it appropriately.

When you're testing your application, keep in mind that you should never overestimate the intelligence of your users. Otherwise, they might surprise you with the different problems they cause in your application. Let's look at an example.

I hate mornings. I am not a morning person. One morning a former coworker woke me up at about 5:30 A.M. with a phone call. Apparently, the main report generated by an application I'd written wouldn't print. Eventually I gained consciousness, and we found that the reporting routine was caught in an infinite loop. Why? The user had entered an order into the system and specified the number of items to build and ship as a negative number.

I'm still not clear on why this user thought entering a negative number of items was a good idea, but I wound up rewriting some code later to prevent users from entering such orders and to allow the printing routine to run successfully even if a negative number did manage to work its way into the database. The moral of the story is: unless you like being woken up at odd hours, do what you can to handle as many problems as possible in the initial implementation of your application.



Programming ADO
Programming MicrosoftВ® ADO.NET 2.0 Core Reference
ISBN: B002ECEFQM
EAN: N/A
Year: 2000
Pages: 131
Authors: David Sceppa

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net