Errors Disarmed, the Cause Function

Carl Sassenrath, CTO
REBOL Technologies
9-Apr-2006 19:13 GMT

Article #0007
Main page || Index || Prior Article [0006] || Next Article [0008] || 11 Comments || Send feedback

In REBOL 3.0, error values are disarmed by default.

Prior versions of REBOL used "hot" errors. That is, you had to treat error values in a special way or they would automatically trigger error processing. This behavior was originally implemented to keep errors from propagating too far from their origins (the principle was to preserve as much as possible the locality of the error).

These hot errors turned out to be overkill, and the benefit of error locality was offset by the difficulty of handling error values in general. (See the articles of Ladislav Mecir who wrote excellent notes on this subject). It could be quite tricky at times.

With that in mind, REBOL 3.0 removes hot errors. Error values (objects)are disarmed by default, and can be treated in the same way as all other objects (e.g. first class: stored, fetched, passed, returned). Functions like try can be used to catch errors and process them as normal values.

In cases where it is required to re-arm an error, forcing it back into a hot state, the cause function has been added. You "cause an error" to be thrown. (Same as Ladislav's description of fire.)

Here is a simple example of handling a specific error:

result: try [... do something ...]
if all [
    error? result
    result/id = 'zero-divide
] [
    cause result

The example evaluates a block and catches all errors. The result (error or not) is stored in result. The code checks if the error is a zero-divide, and if so, throws the error to a higher level of processing (not shown). Note that a disarm is not required.

For compatibility with REBOL 2, the disarm function will still be provided, but it does very little (returns the error object as an object! rather than as an error!, that is all.)

Expert notes:

Internally, the cause function forces stack throw (a long jump in C) which is very fast but major parts of the run time context are lost in the process. By comparison REBOL's break, return, throw functions unwind the stack in an orderly fashion, providing possible debug options during the process.

More information about error handling to come.


Updated 13-Jun-2024 - Edit - Copyright REBOL Technologies -