Appendix 6. Error system

TROEPS generates error messages which are Ilog TALK conditions. These messages are emitted through the signal primitive. Thus, if you want to catch errors in order to manipulate or display them, you must trap these errors or design your own error handler. However, the set of primitives described here is suited for almost every use. Since TROEPS error system is based on TALK objects and generic functions, it is thus easily extendible through refinement.
Note that this interface, unlike the TROEPS API, is made of a number of macro-functions.

Categories of error

An error or warning is a condition (see the TALK reference manual) whose class is a subclass of the <troeps-error> class. It thus shares the condition slots:
Other relevant slots of these objects are:
All these classes are subclasses of the leaves of the hierarchy below.

Figure 18: The hierarchy of errors in the TROEPS error system. It can be extended by the user.

Raising errors

An error can be raised by one of the error raising functions. They create the corresponding error instance and signal it. Each error raising function differs from the set of arguments to be provided (a sub-error or a continuation value).
(troeps.error.raise-error type largs funnam e) macro in [libtrp]

Exit, type symbol, largs ( sexp* ), funname symbol
Signals an error of type type with the corresponding message arguments largs during the call of function funname.
(troeps.error.raise-super-error type largs funname suberror ) macro in [libtrp]

Exit, type symbol, largs ( sexp* ), funname symbol, suberror error
Signals a super error of type type with the corresponding message arguments largs during the call of function funname. The error suberror is placed in the corresponding slot of the raised error.
(troeps.error.raise-recup-error type largs funname value ) macro in [libtrp]

Exit, type symbol, largs ( sexp* ), funname symbol, value sexpr
Signals a recoverable error of type type with the corresponding message arguments largs during the call of function funname. The value value is the continuation value if one wishes to recover from the error.
(troeps.error.raise-super-recup-error type largs funname suberror value ) macro in [libtrp]

Exit, type symbol, largs ( sexp* ), funname symbol, suberror error, value sexpr
Signal a super recoverable error of type type with the corresponding message arguments largs and the calling function funname. The error suberror is placed in the corresponding slot of the raised error and the value value is the continuation value if one wish to recover from the error.

Handling errors

TROEPS provides an error handler which prints the errors and does nothing else (i.e. passes the control to the next handler). For recoverable errors, it prints the error message and returns the continuation value to the program. This handler is activated by calling: 
? (add-handler (function troeps-handler))
This handler can be replaced by another one. The revision system (see below) is based on such a handler.

Trapping errors

An error can be trapped for any kind of treatment. A set of error trapping and processing functions are available in order to process the error instance. These functions usually evaluate some expressions and trap the possibly emitted errors. When no error is raised, its value is returned, when an error is raised a lambda-expression is used for processing the error message.
(troeps.error.check expr type largs funname ) macro in [libtrp]

-> expr, expr sexp, type symbol, largs ( sexp* ), funname symbol
Checks the truth of the evaluation of expr. If expr is not satisfied, raises an error of type type with the corresponding largs and funname.
(troeps.error.encapsulate expr type largs funname ) macro in [libtrp]

-> expr, expr sexp, type symbol, largs ( sexp* ), funname symbol
Encapsulates the evaluation of expr. If an error is raised during its evaluation, it is trapped and introduced as a sub-error in a new error of type type with corresponding largs and funname. This new error is raised in turn. If no error is raised during the evaluation of expr, the result of this evaluation is returned.
(troeps.error.trap-error expr treatment ) macro in [libtrp]

-> expr, body expr, treatment function
Evaluates expr and returns the result of the evaluation. If an error is raised during this evaluation, it is trapped and passed as the only argument of the treatment function which is processed in turn.
(troeps.error.immediate expr) macro in [libtrp]

-> expr, body expr, treatment function
Evaluates expr and returns the result of the evaluation. If an error is raised during this evaluation, this error is trapped and passed as the only argument of the tr-immediate-error-hook method which is processed in turn. Note that no more error is raised afterwards. Thus, if an error has to be propagated, this must occur in the body of the tr-immediate-error-hook implementation.
(tr-immediate-error-hook error) generic in [libtrp]
(tr-immediate-error-hook error) method in [libtrp]

-> expr, error error
Proceeds to a print-error-stack of the error.

Printing errors

An error can be printed with the help of the print-error generic function. Any super-error printed by print-error only displays the outer error message. However, it is possible to print all the embedded error messages with the help of the print-error-stack function.
(troeps.error.print-error error) generic in [libtrp]
(troeps.error.print-error error) method in [libtrp]

->, error error
Displays the error message corresponding to the error on the standard error file ( stderr).
(troeps.error.print-error-stack error) generic in [libtrp]
(troeps.error.print-error-stack error) method in [libtrp]

->, error error
Same as print-error.
(troeps.error.print-error-stack error) method in [libtrp]

->, error super-error
Recursively displays the stack of all errors in the sub-error slot of the error object on the standard error file ( stderr).

Correcting errors and revising assertions

When some particular errors are triggered Troeps is able to help the user in correcting these errors. The revision mechanism can guide the user through the possible revision of the knowledge base (or the initial query) in order to modify it in a consistent way. The revision system is available through the graphic interface when the variable *revision-p* is evaluated to true.

Interface

Screendump 55: Simple error page.

Screendump 56: Non recognised object (or bad URL).

NIY

Screendump 57: Revision page when an inconsistency occurs.

NIY

Screendump 58: Further revision page.