World: r3wp

.....Sounds like it needs a RAMBO and a CC report :)

If it's not in the RAMBO records when they get migrated to CureCode, 
I'll submit it.

Sunanda/Andreas/BrianH: check my comment to the CC #1506 containing 
a B-CATCH/B-THROW example of a dynamic construct allowing an "in 
time detection" of unhandled throw

I am curious, how many users actually use the named Throw?

what is there to throw? :-) ..... hence -1 :-)

Ladislav: very nice

It's always good to see how easily we can emulate changes of internals 
at the REBOL level

I think `:result` should be `get/any 'result`, though

And named throw/catch should be easy to add as well, by just keeping 
a "stack" of handled names

A suggestion: http://bolka.at/share/bug1506-throw.r[temporary URL]

just a side note: I do not like named throws, because they can be 
caught by unnamed Catch, but not rethrown from it (the name is unavailable)

Ah, yes. I don't like that as well, so of course I forgot about it.

:result versus get/any 'result - these are equivalent in R3

Must have tested it with R2, then.

Ok, updated the script so that unnamed catch catches named throws:

b-catch [b-throw/name 42 'foo] ; == 42

but, anyway, when we are at discussing it, isn't there a proposal 
to improve the named throw behaviour?

Is it supposed to actually "emulate" a definitionally scoped catch/throw?

Named catch/throw, you mean?

yes

I'm not sure.

Nevertheless, my guess is, that:
1) named throw is not used by Rebol users
2) it can be safely discarded therefore

Yes, it actually seems to be that way.

I grepped through the R2/R3 mezzanines and some library scripts, 
and this seems to confirm your guess.

will post that to the blog too

I think it actually Boils down to the question what the named catch/throw 
is or should actually

.. be used for.

Is used for: not much. Should be used for: not much as well, as I 
think we could have better solutions for most error handling scenarios.

This would then leave us with the "classical" Common Lisp-style use 
of named catch/throw for non-local exits. And for this use-case, 
a definitionally scoped name would certainly be the right thing to 
do, imho.

Maarten and I used a named throw in a proejct for Qtask, but I don't 
use it much. The question is, *should* we use it more, and what are 
the scenarios? It does make some handling read cleaner to me. 

Maybe Carl can say what he envisioned when he designed it.

Ladislav, your B-CATCH/B-THROW example is similar to what I suggested 
in an earlier comment, but in code form. Nice code :)

And I use names CATCH and THROW.

I never tried to catch a named throw without a named catch. If that 
is possible, that is a major bug and should be reported.

It's possible in R2. CATCH returns the name it caught.

It's possible in R3 as well. I'll report it later.

Extept CATCH returns the value, not the name. Even worse.

Andreas, in R3 :result means GET/any 'result.

Sorry, Ladislav mentioned that already.

Is it a bug, or by design though? i.e. it's a general catch. If the 
name gets lost on a named throw, that seems an obvious oversight 
in the design.

That sounds like an error that should be reported by the console. 
A named throw that doesn't have a corresponding named catch should 
be treated like it doesn't have a catch at all.

We use THROW/name to write sandboxed replacements for the unwind 
functions, non-local dynamic escape functions, etc. But that only 
works if CATCH doesn't catch it.

If that was the original design intent, then I agree.

Reported in bug#1518.

Andreas, the meaning of "non-local" we have been using is code that 
is *not* in a nested block or paren. Instead, the code is in another 
function, a block defined elsewhere, whatever. Definitional scoping 
will only work for local code, meaning code that is in nested blocks. 
We have to define locality relative to the catch, not the throw, 
because the catch function is what defines the scoping.

Gregg, CATCH is not a general catch: There is already the /quit option 
that makes it catch more than it normally would.

Steeve, you might be amused to find out that the DO intrinsic currently 
depends on bug#1509 and does need a [throw] attribute. Though it 
still wouldn't work with definitional RETURN because of binding issues. 
C'est la vie.

I'm working on an FIRE effect for R3, that's how I might be amused 
:)

Brian, if a simple CATCH should not catch named throws then we need 
a CATCH/ALL (not sure if /QUIT should be it).

Gabriele, Brian requested such a thing (CATCH/ALL) as bug#1520.

Though he wants bug#1520 to catch all other unwinds (BREAK, CONTINUE, 
RETURN, EXIT) as well, to which I see no merit.