Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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