2.7.15.5 Computable Error Messages

The automatic generation and reporting of error messages provides a reasonable default behavior for applications that do not consider exceptional conditions. All applications and their input data are ordinarily members of the bottom level set in the hierarchy (A Hierarchy of Sets). The error messages caused by invalid operations on this level are on the first level above the bottom, which are recognized as such and written to standard error without intervention from the application. However, there are two drawbacks to this style of dealing with exceptions.

• An application developer may wish to translate error messages into terms that are meaningful to the user, not only by literally translating them from English to the local vernacular, but perhaps by relating the particular exceptional condition to application specific causes. While it is convenient for the “back end” code not to be required to intervene in the error reporting, it would be most inconvenient for it not to be able to do so.
• Some application specific errors might not correspond directly to any of the particular conditions detected automatically due to invalid operations, for example a semantic error in a syntactically correct input file. It might be convenient in such cases for an application to be able to define its own error messages but still have them reported automatically like the built in messages.

These situations suggest a need for some ability on the part of an application to operate on error messages themselves. Based on the operator semantics given so far, such an application is inexpressible, because for any application f_0 and error message x_1, property P44 stipulates f_0 x_1 = x_1, meaning that the resulting error message is unchanged. Therefore, we need to define another basic property of the operator.

The following form of virtual code is used in applications that may need to operate on error messages.

T32

[[guard]] (f,g) = ((nil,f),g)

Code in this form has the following semantics.

P53

([[guard]] (f,g))_n x_p = g_(n+1) f_n x_p

The intuitive explanation is that f is the main part of the application, and g is the part of the application that operates on the error message that comes from f if an exception occurs while it is being evaluated (i.e., the “exception handler”). Typically the exception handler code implements a function that takes an error message as an argument and returns an error message as a result.

Where there is no exception, the exception handler g_(n+1) is never used, because its argument will be on level n, and therefore unaffected by an application on level n+1.

Exception handlers may have their own exception handlers, which will be invoked if the evaluation of the exception handler causes a further exception. Such an exception corresponds semantically to a value on the next level of the hierarchy of sets.