[REBOL] Re: Tools for Rebol Coders
From: lmecir:mbox:vol:cz at: 8-Jan-2002 17:40
I could agree with Ladislav when he asks a change in the actual error!
specific. But i do not think that the actual implementation of Return error!
is a bug.
For me it doesn't matter whether it is a bug or not. I just prefer and
propose a more reasonable behaviour.
About Ladislav's Rep, i want to ask him:
0) The by-default-disabled error! is an object! or a error! datatype?
1) When an error is Fired, can it be catched by try?
2) Have you thought about throw err: try [...] ? Don't we need a sort of
3) Normally when an error is throw, it is catchable without try. What
in your proposal?
0) I prefer it to be an ERROR! datatype value.
1) I think, that this sample code can illustrate what I mean:
fire: func [[catch] error [error!]] [
error? try [fire make error! "my-error"]
fire make error! "my-error"
2) There are two possible answers to this question. The first one is: there
is no need to introduce a new function. Even now the [catch]/throw differs
from catch/throw (the former pair works only for errors and "fires" them,
the latter works for any Rebol value and doesn't necessarily fire errors).
The second one is, that because the mechanisms differ a lot, they should be
distinguishable. It is a matter of preference only.
3) I think, that the catch/throw mechanism (which differs from
[catch]/throw) should work as it does now.
I think that a big problem about the implementation of error and Return is
interaction with functions attributes [catch] and  (which throw a return
only if is argument is an error!). It is strange, undocumented or buggy (as
you like) and all these things constrain to make "strange" things with third
of functions to construct trasparent functions (like in Ladislav's
There is a need to have transparent functions in Rebol. (They are useful for
new control functions creation.) My implementation is only a hack, because
it is a self-modifying code, which is ugly IMHO. The only reason, why it is
so ugly, is the behaviour of Rebol errors, which unreasonably complicates