Next: Tail Recursion and Up: Psd - a Portable Previous: Runtime Support

Catching Runtime Errors

A typical use of a debugger is to let the program run until a runtime error occurs and examine the program state to find out what went wrong. With Psd, real runtime errors can not be allowed to happen, since it relies on correct execution of the instrumented code. Instead, if an expression would cause a runtime error to occur, the command loop is called and an error message is issued.

Aside from syntactically incorrect expressions and causes outside the scope of the language (exhaustion of memory, receiving a signal etc.), the only place where a runtime error can occur is the procedure call. When calling a user defined procedure, the only possible error is that a wrong number of arguments is supplied. Although it would be possible to detect at least some of these errors, Psd does not currently check the number of arguments to a user procedure.

The number of primitive procedures is fixed, so they are easier to handle. Psd transforms each procedure call (proc args) into (psd-apply proc args). Before psd-apply applies the procedure to its arguments, it checks if the procedure is a primitive procedure. If it is, psd-apply checks that the number of arguments is correct and that the arguments are of correct type. If a runtime error would occur, psd-apply calls the debugger command loop. Runtime errors that occur in non-debugged code can not be caught this way.

There are still some cases in the current implementation where a runtime error can occur. For example, for the assoc procedure, the second argument should be a list of lists. Currently, it is only checked that it is a list.


pk@
Fri Feb 11 09:35:36 EET 1994