VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

VB .NET - Learn Visual Basic .NET

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 11

Handling Errors in Code - Error-Handling Routines

This chapter has already discussed the Err object and has also examined the options for the On Error statement in Visual Basic. In addition, the error-handling routines within sub-routines and functions have been mentioned. This section continues the discussion of errorhandling routines in procedures and recommends some standards for their creation.

Error-handling routines are sections of code that are executed in the event of an error. They can range from being very simple with only a few lines of code to being very lengthy. Unlike inline error handling, using an error-handling routine enables you to localize all your exception processing in one place within a procedure.

Some things to remember when you code error routines within your Visual Basic procedures include the following:

  • Keep your error-handling routines simple. If another error occurs in your error-handling routine, your application will generate a fatal error and shut down.

  • Error-handling routines are generally found at the end of a procedure. Make sure that you put an Exit Sub or Exit Function statement before the error-handling routine so that during normal execution, your program does not fall through to the error-handling code.

  • Use the On Error Goto <line> statement to control program flow in the event of an error.

  • Anticipate the types of errors that are common to the functionality of your code. This will enable you to handle different errors in different ways. It could also prevent fatal errors from occurring (see "Trappable Errors" later in this section).

  • If you need to display error messages to users, provide information useful to them. A user typically does not understand errors such as Invalid File Format. Instead provide a message that states The file you selected is not an Excel spreadsheet.

  • When you display error messages to the user, also include information that will help you—as the developer—track down errors. Include the form, class, or standard module name. Identify the procedure in which the error occurred. Add any other additional information that will help you find and correct problems.

  • Consider logging errors. You might wish to implement some sort of persistent record of errors (writing to a text file or database, for example). This will take the burden for error reporting off the user who could forget or misreport error messages. If you decide to log errors, however, be aware that logging routines themselves might cause runtime errors (since database and text file access are prime sources of runtime errors).

  • Whenever possible, give the user the chance to correct problems. If they try to read a file from a floppy drive and forget to insert a disk, for example, provide an opportunity for them to retry the operation.

No matter how hard you try, conditions beyond your control will sometimes cause errors to occur in your application. Using some or all of the preceding tips will provide a more user-friendly environment for your users. These tips help provide more information to the user when an error occurs, and will also make it easier to track down and debug problems in an application.


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved