Greg Nelson, Digital System Research Center
Article from Threads
Modula-3 defines a "checked run-time error" as an error that implementations
must detect and report at run-time. For example, using an array
index that is out of bounds is a checked run-time error.
The method for reporting checked run-time errors is implementation-dependent.
For example, in a program development environment, the most
useful implementation action would probably be to enter a debugger.
However, in an operating telephone switch, appropriate actions would more
likely include logging the error and restarting the switch software.
Proponents of mapping checked run-time errors to exceptions argue that
the language should be changed to require implementations to raise
predefined exceptions on checked run-time errors. This would give programmers
maximum flexibility to recover from the error in whatever manner
is appropriate for the application. But this argument doesn't stand
up to scrutiny.
First, when a checked run-time error is detected, the appropriate recovery
action almost always requires implementation-dependent actions.
Changing the language to provide an implementation-independent way
to detect such errors only postpones the problem. For example, there is
no
implementation-independent way to enter a debugger, to log an error,
or to restart a server.
Second, it is important to realize that checked run-time errors can
occur in threads that are forked by libraries, as well as in an application's
main
code path. If errors were mapped to exceptions there would be a need
for "TRY" statements to handle these exceptions wherever a thread forked.
When a program moved from testing into actual service, and the appropriate
error recovery action changed, it would become necessary to modify
many "TRY" handlers scattered throughout the program.
A better strategy is to let the implementation determine the error recovery
action.