Microsoft KB Archive/34404

From BetaArchive Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Article ID: 34404

Article Last Modified on 11/21/2006



APPLIES TO

  • Microsoft QuickBASIC 4.0b
  • Microsoft QuickBasic 4.5 for MS-DOS
  • Microsoft BASIC Compiler 6.0
  • Microsoft BASIC Compiler 6.0b
  • Microsoft BASIC Professional Development System 7.0



This article was previously published under Q34404

SUMMARY

This article discusses global error trapping, which is found in the following products:

  1. QuickBasic Versions 4.00b and 4.50
  2. Microsoft Basic Compiler Version 6.00 for MS-DOS and OS/2, and the accompanying QuickBasic Version 4.00a
  3. Microsoft Basic Compiler Version 6.00b for MS-DOS and OS/2, and the accompanying QuickBasic Version 4.00b
  4. Microsoft Basic PDS Version 7.00 for MS-DOS and OS/2

Global error trapping is not found in QuickBasic Version 4.00 or earlier versions, in which error trapping is local to each separately compiled module.

The following explains how global error trapping works:

In a multiple-module program, an ON ERROR GOTO 0 statement turns off error handling only in that module. Error handlers activated in modules at any higher procedure CALL level remain active, and will trap the error.

This feature localizes the impact of error handling to each module. This allows software vendors to deliver .OBJ modules that trap errors for their modules only. An error handler in the main program will handle errors in linked modules if those modules do not trap errors themselves.

This behavior of error trapping differs from QuickBasic Versions 4.00 and earlier, in which modules at a given procedure CALL level do not handle errors that originate in separately-compiled modules at deeper CALL levels.

MORE INFORMATION

The following code example is composed of a main program that is linked to a separately compiled subprogram. Error trapping is set up and turned on in the main program, and the subprogram is called. The subprogram turns off error trapping locally, and then forces an error to occur.

When compiled in QuickBasic Versions 4.00 or earlier, the program aborts with the error in the subprogram. When compiled in QuickBasic Version 4.00b or the Basic compiler Version 6.00 or later, the error is trapped by the main program's error handling routine because of the global error handling feature described further below.

'===== Main module: MAIN.BAS =====
DECLARE SUB sub1 (a!)
' The main module's (global) error handler is turned on as follows:
ON ERROR GOTO 500
CALL sub1(10)
PRINT "End of test program."
END
'Main/Global error handler:
500 PRINT "in main"
PRINT ERR
RESUME NEXT

' ===== module 2: SUB1.BAS =====
' This module is in a separate file on disk.
'Module 2's error handler at line 400 is not turned on.
400 PRINT "in mod 2"
PRINT ERR
RESUME NEXT
SUB sub1 (a)
    ON ERROR GOTO 0   'turns off local error handling in module 2.
    PRINT "error off"
    c = 10
    g = 0
    PRINT c / g       'forces a "division by zero" error
END SUB
                

The following information about global error handling was taken from the UPDATE.DOC file on the QuickBasic Version 4.00b release disk:

Enhanced Error Handling in QuickBasic 4.00b and BASCOM 6.00

Microsoft QuickBasic Version 4.00b includes an important new error-handling feature for multiple-module programs. See Chapter 6 of "Programming in Basic: Selected Topics" for a thorough discussion of error handling and event handling.

In previous versions of QuickBasic, an error in a module that did not contain an error handler caused the program to terminate immediately, even if an error handler was present in a different module. QuickBasic 4.00b first looks for an active error handler in the module where the error occurred, then in the module that invoked that module, and so on. QuickBasic follows the chain of procedure invocations back until it finds an active error handler or reaches the program's main module. If QuickBasic cannot find an error handler by this process, the program terminates with an error message.

However, please note that if the error occurs in an event-handling routine, QuickBasic does not search for an error handler beyond the module that invoked the event handler.

This feature affects the behavior of the RESUME statement. In previous versions of QuickBasic, RESUME caused the program to resume execution at the "current statement," meaning the statement that caused the error. In a QuickBasic 4.00b multiple-module program, however, the "current statement" is the last executed statement in the module containing the active error handler.

The new error-handling feature has a similar effect on the ERL function. In QuickBasic Version 4.00b, the program line that the ERL function identifies as the source of an error is the line that contains the last executed statement in the module where the active error handler is located.


Additional query words: QuickBas BasicCom

Keywords: KB34404