[REBOL] Re: Tools for Rebol Coders
From: rotenca:telvia:it at: 8-Jan-2002 18:48
Hi Ladislav,
>> 2) Have you thought about throw err: try [...] ? Don't we need a sort of
>> fire-throw?
>> 3) Normally when an error is throw, it is catchable without try. What
>> happens in your proposal?
> 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.
And how to throw and fire an error? If we do in your proposal:
throw make error! "my-error"
we do not fire our error! and if there is no catch, we end with an
** Throw Error: No catch for throw: "my-error"
** Near: throw make error! "my-error"
if there is a catch we have not error at all.
instead of (not catched)
** Throw Error: ** User Error: my-error
** Near: throw make error! "my-error"
or (catched and evaluated)
** User Error: my-error
** Near: throw make error! "my-error"
we must always use the [catch] attribute to fire-throw the error?
And if the throw is a script file which some code do, instead of a sub func,
what happens?
> 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
> things.
I agree, but I think that the function attributes implementation requires a
deep revision.
---
Ciao
Romano
