World: r3wp

A better example of the foreach loop:

foreach [code handle] [
	[1 / 0] [print "error 1"]
	[2 / 0] [print "error 2"]
] [
	if error? try code [do handle break]
]

If last error was kept in a system variable (so we could get it there), 
the /EXCEPT refinement would make better sense.

Maybe it is in system/state/last-error

No, doesn't seem to work, if you handle the error yourself.

Geomol, set-word assignment uses the SET function, which by default 
doesn't accept error! values (by design). If you want to assign error 
values then use SET/any.

Geomol, maybe you're missing that /except accepts a function, ie. 
try/except [...] func [error] [probe error]

Gabriele, yes, I didn't see that. So it should be possible to do, 
what I considered.

Brian, no, it works here (version 2.100.95.3.1). Do this:

if error? result: try [1 / 0] [probe result]

It's unset!, SET can't set, not error!.

Weird, that shouldn't work. That should be reported.

It looks like untriggered errors are assignable with set-words in 
R3. I wonder if that was an intentional change. It should be reported 
as a bug, with a request for Carl to say whether it was intentional.

I reported the bug in #1515, recommending that it be declared not 
a bug. However, when combined with #1509 it turns into a nasty security 
bug (similar to #1004). We really need to fix #1509 asap.

Brian, why do you think that errors should not be assignable with 
set-words?

Raising again the now popular subject of error handling, I'd've thought 
this line of code should always print 'true....
    attempt [do "while [] []"] print 'true

....after all, it has no explicit 'RETURNs or 'BREAKs etc. It's just 
a bit  of unarguably bad code wrapped in an ATTEMPT.

(Not sure if this is a new test case, or (to Brian) an obvious application 
of the known issues; I think of it as a bug:)

And, on the same topic. R2 and R3 have divergent opinions on how 
to handle this line....
    while [return 55][print 1]
....Neither of them convincing me that they are right.

It  fails in the intrinsic part of DO, I guess  (which is a mezz).
And as we know well, Mezz can't have [throw] attribute currently

Gabriele, I don't think that, which is why I recommended that it 
be declared not a bug. I was just surprised. I do think that unwinds 
should not be assignable though, as that is a security hole and part 
of a greater problem with their operation.

Sunanda, we can't block non-trivial bad code without semantic analysis, 
which would have to include consideration of the programmer's intentions, 
which the interpreter *can't know*. And blocking trivial bad code 
would require similar analysis, but would not be worth the effort 
because people don't write trivial code.

And the while [return 55][print 1] behavior is because of bug#1509, 
it's not intentional.

Steeve, the intrinsic part of DO isn't called by DO block!, just 
by DO string!, DO file! or DO url!.

Sunanda, we only have your word for it that do "while [] []" is bad 
code. You have done nothing to tell the interpreter that it is bad, 
and other programmers might be doing it on purpose. The interpreter 
can't tell the difference: It's all in your head. That's not an insult, 
it's an unresolvable communication problem between your intentions 
and the interpreter. The interpreter has to take you at your word, 
what you said to it is do "while [] []". Which it can, so it will.

R3 isn't psychic. Anyone want to write an extension for that? Maxim? 
:)

I'm well aware of this, Brian :)
>> attempt [do "while [] []"] print 'true

And if i can trust my eyes,   it''s a DO string! in Sunanda's example

Not just my word. Brian. If I type....
  do "while [] []"

..... in the console (R2 or R3), the _console_ tells me it is bad 
code.


Now, without wanting to reopen all the dicussion that has gone before, 
at the very least, this establishes that the console is not (in some 
cases) a good guide to how a line of code will be interpreted in 
a larger script.


Which goes against the traditional advice that the console is your 
friend -- such as offered here:
   http://www.rebol.org/ml-display-message.r?m=rmlMGGC

right, Sunanda, I guess, that this is related to CC #851

(and that it has to be corrected)

Re the while [return 55][print 1] behaviour in R2 - that is clearly 
caused by the fact, that the COND-BLOCK is (esp. in R2) handled differently 
than the BODY-BLOCK; the behaviour of UNTIL looks OK in R2

Steeve, I thought you were talking about the while [return 55][print 
1] code, which would be affected by the [throw] attribute because 
it has a return in it. The attempt [do "while [] []"] print 'true 
does get processed by the intrinsic, but doesn't fail (it works correctly) 
and wouldn't be affected by [throw] because it doesn't have a return 
in it.

Then, how do you explain this ?

>> attempt [do "while [][]"]
** Script error: block did not return a value
** Where: while catch either applier do attempt
** Near: while [] []

>> attempt [do [while [][]]]
== none

Sunanda, whoops, you meant the TRY [CATCH/QUIT [...]] bug. It's already 
been reported.

Ladislav mentioned it: #851.

Well, it's comming from the intrinsic part still :)

Right. I just thought that you were talking about his other code 
because of the return. Interestingly, while [return 55][print 1] 
is buggy in both R2 and R3, but the bugs are different.

Sunanda, it turns out that the while [return 55][print 1] bug hasn't 
been reported yet. It's related to bug#1509, but not quite the same 
thing. I'll report it later today.

Thanks, Brian.....

.....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