Exception handling

One of the problems of submitting the client code to the server is what happens when a call fails. The server programmer knows when a server call has failed, so he or she can decide to terminate the program, in that case. This can be done by calling the terminate method of the Program class from a run method. However, the client could wish to continue the program despite any failures. To support this, we have included two commands in our pattern instances: AbortOnError and DoNotAbortOnError. They allow the user to switch between the two modes. When AbortOnError has been called, a call to terminate causes program termination; otherwise it has no effect. In this way, the client can control the effects of a failed call.

The implementation of terminate depends on both the kind of instruction set being implemented and on the implementation language. A byte-code based program can be stopped very easily as there is a main control loop (in the run method), just by setting a terminated flag to true. Stopping an structured program (e.g. the one used in our file server example) is a little more complicated. This is due to recursive interpretation: calls to run in Programs propagate calls to the run method of its components. To stop that program, it is necessary to finish all the nested run calls. Depending on the implementation language it can be done in a way or another. In a language with exceptions, like C++ or Ada, it suffices to raise and propagate an exception in the code of Terminate, catching it in the run code of Program. In languages like C, setjmp can be used in the top-level run method before calling any other run, and longjmp can be used, for the same purpose, in the body of terminate.