| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 13)

Handling Errors in a Procedure

 When G2 signals an error during procedure execution, or a user-supplied procedure signals an error, the signaler specifies the type of the error by supplying an error object of appropriate type.

In either case, G2 searches the call stack back from the point where the error was signalled, looking for a block error handler whose type matches that of the error object. Since error is the parent all error classes, a block error handler that specifies the class error matches any error. A handler that specifies a more specific subclass matches only errors of that class and its subclasses.

If G2 encounters a block error handler whose class matches the class of the error object, G2 executes the statement(s) in the body of the error handler. These statements can reference the error object in any standard way.

If G2 never finds a matching block error handler, it executes the default error handler. The system-defined default error handler is an on error statement that:

  1. Takes an object of class error, and thus matches any error.

  2. Posts the class of the error, and the contents of its Error-description attribute, to the Operator Logbook.

After an error handler has executed, control passes to the first statement after the end of the block that experienced the error. If no such statement exists, the procedure containing the block returns.

Synchronous and Asynchronous Error Handling

Error handler invocation is synchronous: nothing else will execute in the G2 that executes the handler until that handler returns. If the error did not occur during execution of an RPC call, and the error handler does not execute an RPC call, the G2 context is guaranteed to be the same when the handler returns as it was when the handler was invoked, except insofar as the handler itself has changed it.

When error handling either executes or occurs during execution of an RPC call, the remote process runs asynchronously from the error handler, and can change the context of the code that invoked the handler. When the handler returns, code that validates context may have to be rerun before code that assumes that context can safely continue execution.

Default Handler Example

The following procedure attempts to call an undefined procedure named sigproc:


If you invoke demonstrate-default-error-handler, the procedure:

  1. Posts "Call Sigproc Now:" on the Message Board.

  2. Attempts to call sigproc.

G2 cannot find the nonexistent procedure, so it:

  1. Creates a transient error object of class g2-error and sets its Error-description attribute to describe the error.

  2. Signals an error with that error object.

To process the signaled error, G2:

  1. Seeks a block error handler that takes a g2-error.

  2. Does not locate such a handler,

  3. Invokes the default error handler, passing it the error object.

The system-defined default error handler:

  1. Posts the following message on the Operator Logbook:


  2. Deletes the error object. See Error Object Memory Management for information on error object deletion.

An error aborts the block that experiences it, so the statement posting "Return from Sigproc:" on the Message Board never executes. Since demonstrate-default-error-handler contains no further statements, the procedure returns.

Block Error Handler Example

The following procedure attempts to call an undefined procedure named sigproc. It is the same as the preceding example, except that it defines a block error handler on the calling procedure's begin-end block:


If you invoke demonstrate-block-error-handler, the procedure:

  1. Posts "Call Sigproc Now:" on the message board.

  2. Attempts to call sigproc.

G2 cannot find the nonexistent procedure, so it:

  1. Creates a transient error object of class g2-error and sets its Error-description attribute to describe the error.

  2. Signals an error with that error object.

To process the signaled error, G2:

  1. Seeks a block error handler that takes a g2-error.

  2. Locates the error handler associated with the procedure's begin-end block.

  3. Invokes the handler, passing it the error object.

The block error handler:

  1. Posts the following message on the Message Board (not the logbook):


  2. Deletes the error object. See Error Object Memory Management for information on error object deletion.

The error aborts the block, and demonstrate-block-error-handler contains no further statements, so the procedure returns.

Note that the value of Error-description in the Message Board is message the same as in the Operator Logbook message in the previous example. It is the same because the error object generated by G2 is the same in both cases. The only difference is the handler that posts the information: the system-defined default error handler in the previous example, and a block error handler in this one.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 13)

Copyright © 1997 Gensym Corporation, Inc.