World: r3wp

Nevertheless, at least for Return and Exist this does not look like 
an issue, since binding is likely to occur anyway in these cases

Exit is what I meant above

and, the speed difference for Return and Exit may still exist, but 
only if the respective function does not have any parameter

I think that the implementation of improved error causation as described 
by Brian in bug#1506 would be very worthwile and should be pursued.

 - again, this is a thing I discussed with Carl quite long ago, but 
 it seems, that Carl disliked the fact, that the implementation would 
 have to be more complicated, than it currently is, while the effect 
 Sunanda would like to achieve is probably achievable even now

Do you really think it would complicate implementation much?

Thanks for your feedback, in any case.

not me, it is what Carl thinks, if I understood him well

I have to confess, I'd love to read through those discussions (if 
actually were in writing :).

Carl says he is going to work on the documentation about how errors 
work.

I guess that means he has no intentions of improving error causation?

No, it just means that he wants to start the conversation from a 
good baseline.

Fair enough.

We've been able to find out a lot from stuff posted so far and the 
scientific method though :)

I think a lot of the problems would be solved by just letting developers 
plug in their own recovery code into the console handler, and that 
would be more efficient too.

Yes. Or more generally, a special CATCH version (along with a proper 
predicate) that allows us to set up our own catch-all default handler.

You can already have a catch-all handler:

do does [catch [attempt code]]

add a loop 1 somewhere :-)

>> do does [loop 1 [catch [attempt [1 / 0]]]]
== none
>> do does [loop 1 [catch [attempt [exit]]]] 
>> do does [loop 1 [catch [attempt [return 10]]]]
== 10
>> do does [loop 1 [catch [attempt [break]]]]    
>> do does [loop 1 [catch [attempt [break/return 10]]]]
== 10
>> do does [loop 1 [catch [attempt [throw 10]]]]       
== 10
>> do does [loop 1 [catch [attempt [throw/name 10 'something]]]]
== 10

(this was R2 but barring bugs it should be the same on R3)

Yes, except for bug#851, which creates a no-catch situation

(and, you omitted Try)

Ok, let's start here:

http://www.rebol.com/r3/notes/errors.html

Ladislav: actually, I agreed with you.  RETURN and EXIT should be 
definitionally scoped!

PS: I've always agreed on that.  The question is how best to implement 
such a thing.

doc says "preformed". intentional?

typo!

I think my fingers type "reform" on their own, so "preform" is automatic.

:-)

A new section added: True Error Capture.

does any of this describe release A98 behavior or is it A97 behavior?

Did it change?

I'm not saying that. I'm just asking if there is any new development 
in error handling between A97 and A98.

No, I wasn't planning on it, because A98 is related to other things. 
But, eventually it would.

I wrote the doc because we do need to solve this issue... probably 
in A99 or A100.

ok

And also, because it was a hot topic above... with many of the key 
people chatting on it. So, good time to get it finalized.

OT: It's interesting, the term "dynamic lexical scoping" produces 
no direct hits on google. Only references to dynamic or lexical scoping. 
OK, back to topic. :-)

I probably should quote that.  BTW, in REBOL definitional scoping. 
So run-time lexical.

fixed

The example just below that sentence with definitional scoping: I 
agree on that.


I ran into exactly this issue just last night in an attempt to wrap 
some function bodies in a primitive callstack mechanism (R2 code) 
so I could debug it easier. The debugging mechanism kept crashing 
there, because it ran straight through the first 'return and "returned" 
twice.


R3 of course doesn't need function scoped return for that reason, 
since I can already see the stack trace on an error, but for other 
reasons (correctness?).

Possible Return Method: Using set-word! in function spec could also 
be confused as default value for an argument. Only beginners would 
do that, I suppose.

Yes, but word, :word, and 'word are taken.

Other set-words might be catch: throw: trace: debug:

any comment towards !REBOL3 GUI wait & CPU sleep times topic? :-)

try/handle is one char shorter than try/recover :-)

alternatively:

try [block]

handle [block][error handler]

Anything shorter than handle? :-)

not sure, at least not without losing the meaning

try/do
try/on-error