virtual pattern is instantiated and executed. These patterns are specializations of errCB, as declared in errorCallback. Such virtual patterns are hereafter denoted error callback patterns. To catch and treat an error, extend the corresponding error callback.
If an error callback is not extended and the corresponding error occurs, an exception is executed and the program terminates. If the error callback is extended, the following holds:
if abort is executed in the extending dopart, the operation (but not the program) is aborted. You may execute leave within a specialization of abort. Do not leave an error callback from any other point, as this may put the object or the process into an unstable state. If you abort but do not leave, the operation aborts, but control flow is like when the operation succeeds; in this case, any exited values are dummy values, reflecting that the operation failed. Do not use them! Actually, do not abort without leave!
if continue is executed in the extending dopart, there will be an attempt to recover and finish the operation after the execution of the error callback terminates. For many types of errors, no general recovery is possible at the operation level. But you could close a couple of files in response to a resourceError and then execute continue. In case of timeout, you can always choose to take another turn with continue.
if fatal is executed in the extending dopart, an exception will be executed and the program will be terminated. So the execution of the error callback will not return. This is also the default, but with hierarchical error callbacks, you may need fatal to undo a continue at a higher level.
In case it happens more than once that an operation from the set {abort,continue,fatal} is executed, the one executed as the last takes precedence.
| Process Libraries - Reference Manual | © 1994-2002 Mjølner Informatics |
[Modified: Friday October 20th 2000 at 14:22]
|