R Condition Handling

Cited from Beyond Exception Handling: Conditions and Restarts

In a well-written program, each function is a black box hiding its inner workings. Programs are then built out of layers of functions: high-level functions are built on top of the lower-level functions, and so on. This hierarchy of functionality manifests itself at runtime in the form of the call stack: if high calls medium, which calls low, when the flow of control is in low, it’s also still in medium and high, that is, they’re still on the call stack.

Each function–low, for example–has a job to do. Its direct caller–medium in this case–is counting on it to do its job. However, an error that prevents it from doing its job puts all its callers at risk: medium called low because it needs the work done that low does; if that work doesn’t get done, medium is in trouble. But this means that medium’s caller, high, is also in trouble–and so on up the call stack to the very top of the program. On the other hand, because each function is a black box, if any of the functions in the call stack can somehow do their job despite underlying errors, then none of the functions above it needs to know there was a problem–all those functions care about is that the function they called somehow did the work expected of it.

A condition is an S3 object whose class indicates the general nature of the condition and whose instance data carries information about the details of the particular circumstances that lead to the condition being signaled.

Conditional classes are regular S3 classes, built up from a list with components message and call. There is no built in function to generate a new object of class condition.

stop() is normally just called with a string, the error message, but you can also call it with a condition object.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Cited from A Prototype of a Condition System for R