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.)
cause could accept other values too please, and then do nothing.
that would allow
result: try[..]
cleanup
cause result
and if there was no error, nothing is thrown.
Carl Sassenrath 9-Apr-2006 16:43
Yes, that is possible. Good idea.
maximo 9-Apr-2006 17:48
actually, it could simply return the value, if it was not an error... (like probe)
thus we could choose between returning or causing. without error, both would be safe and happy.
Carl Sassenrath 9-Apr-2006 18:03
That's the way it's been implemented.... so we will see how it works out.
Brian Hawley 10-Apr-2006 12:59
Would there be a debug mode that would make cause unwind the stack properly so that you could get a stack trace? Or would this not be necessary?
Gregg Irwin 10-Apr-2006 14:13
I don't care for the word CAUSE. It's not an active verb, and doesn't read well to me at first glance.
What about adding a refinement to THROW?
On a side note, will MAKE create a hot error, or will you need to throw the result to make it hot?
Volker Nitsch 10-Apr-2006 15:48
:)
How about
> result: try[..]
> cleanup
> throw? result
"throw? throws if arg is an error, returns it otherwise.
The errormessage ("near:" etc) is not changed."
Btw about errors, how about adding a usermessage on tries? following errorhanding is usually tricky, an "annotated" stacktrace may help.
Gabriele 10-Apr-2006 18:28
:)
Gregg, isn't "to cause" a verb? To cause an error? It actually reads better to me than "to throw an error" (but I guess programmers are more used to the latter).
Gregg Irwin 10-Apr-2006 19:09
"cause" is a verb, yes, but I don't know anyone who says "cause ". THROW certainly isn't an normal English term here, but it's a known domain term that already has this meaning, hence my suggestion for a possible refinement.
We could use something like "cause-error" to make it read better (IMO). The example Carl posted is a good example of something that doesn't read well to me. i.e. :
cause result
Gregg Irwin 10-Apr-2006 19:11
First sentence should have read:
"cause" is a verb, yes, but I don't know anyone who says "cause (something to happen)".
Put the paren phrase in angle brackets the first time; must have been stripped.
Tamás Herman 10-Apr-2006 21:54
:)
a note about naming:
most programmers find EITHER very strange as well. most of my collegues became frightend and were desperately looking at me why do i care about such an excentric programming language.
so i wouldnt divert from the well established names UNLESS we really want to reform the programming world and want to frighten away those close minded "so-called programmers" :)
i like conciseness so i would prefer a single word over refinement, but i dont know how frequently would it be used compared to a bare THROW
