World: r3wp

But it's not EXIT that is generating the error. EXIT itself is innocent.

Sunanda, you are ignoring context. None of those generate an error. 
It is the code surrounding that code that generates the error.

Wait, the THROW/break ones always generate an error. THROW doesn't 
have a /break refinement.

But the only code surrounding it is the console!

Yup, that is what is generating the error, the console.

And the first two THROW/name examples are wrong too, because of argument 
compatibility.

Then the console is broken!

No, it's doing its job. It is only context that makes that code erroneous 
(except for 5 argument errors in your examples).

THROW 0 is always correct in and of itself. It's not THROW's fault 
you called it outside of a CATCH, it's yours.

So how to catch concole errors then?

Simply put - we have to have chance to catch ANY level erorrs - your 
app can't crash on you, without your control imo ...

The problem is that the code he is complaining about isn't actually 
erroneous.

How then can I get this code, executed from the command line, to 
always quit?
  r3-a97-3-1.exe --do "print true attempt [exit] print true quit"

does it not print an error message?

It's the missing CATCH that is the error, not the THROW.

I guess ATTEMPT is no longer an extension of error? try like in R2.

No, but it works the same, just faster. Almost all functions that 
had a [throw] attribute in R2 (or needed one, like ATTEMPT) were 
converted to natives in R3. We're still waiting for the new equivalent 
of the [throw] attribute to be added to R3 - right now USE, OBJECT 
and CONTEXT are the only built-in functions that still need it, afaik.

Note that the ticket was marked as a problem, not dismissed (yet). 
The problem was explained in the comments, and more thoroughly now 
in my more recent reply there.

I think I can answer my own question about executing arbitary code.

Just tried the ancient error? try technique:

   error? try [break]  ;; I'm happy
   attempt [break]   ;;  still think this is a bug!

Actually, the first is an error too. It turns out that the way BREAK, 
EXIT, RETURN, THROW, HALT and QUIT work is by throwing pseudo-errors 
that are technically instances of the error! type, but not really 
errors. The ERROR? function disables that throwing for all error! 
values, even the fake ones. It's an error in ERROR?.

There's even a CureCode ticket for it, which you referred to in your 
comment.

It's the same error as RETURN BREAK.

From my perspective, attempt [break] is working correctly. ATTEMPT 
has nothing to do with the BREAK, it simply passes it to the outer 
context (if you can say that) and then the BREAK doesn't hold up, 
because it's not inside a function. Seems simple to me.

Loops, but yeah.

yes, sorry, loops, not functions.

loop 2 [attempt [break]] works as expected.

>> a: does [attempt [exit] 1]
>> a
>>

Looks fine and dandy.

What would you expect from:
  loop 2 [print true attempt [break] print true]
true printed 0..6 times?

Or:
  loop 2 [print true attempt [continue] print true]

Once, and it did.

Twice, and it did.

The question (only for Carl) is whether task-local runtime contextual 
information can be made available to BREAK, EXIT, RETURN and THROW 
to let them know that they are going to be handled by the console, 
which would let them throw the error that the console should be throwing, 
on behalf of the console. Basically, letting them be more polite. 
The problem is that it is *really* likely (only Carl would know) 
that this would slow down all function! and closure! calls, all loops, 
and every call to DO (even indirectly, as in IF) by quite a bit. 
It could make R3 a lot slower (maybe several times slower).

I'm not sure what you would expect here. Wrapping break and continue 
in attempt has no effect, because we know there are no errors inside 
the attempt block and the context outside is correct for break and 
continue. The attempt has absolutely no effect here.

Right.

I'm curious now: How do those functions know they are inside loops 
and functions?

They ask Carl :-)

They don't, not in the slightest.

They are thrown like exceptions. The default handler is in the console.

I see. That further proves how little ATTEMPT has to do with these 
errors. :-)

And in REBOL there is no way to statically determine whether an exception 
will be handled without tracing the code. You could in theory determine 
it at runtime (from the internals), but that would have overhead. 
The question is how much overhead.

ATTEMPT and TRY push a handler for exceptions with codes over 100 
on the task-local handler stack. Those exceptions are generated by 
DO MAKE error! (or code called by natives with the same effect).

The interesting part of the default console handler is that it is 
exactly the same handler that displays regular errors. The messages 
come from here:
>> system/catalog/errors/throw
== make object! [
    code: 0
    type: "throw error"
    break: "no loop to break"
    return: "return or exit not in function"
    throw: ["no catch for throw:" :arg1]
    continue: "no loop to continue"
    halt: ["halted by user or script"]
    quit: ["user script quit"]
]

Sorry for the awkward phrasing above. The comments in the ticket 
read better.

Brian, I agree with you.  I think if we make Try or Attempt handle 
these other exceptions then we are going to slow things down.  Again, 
we have  a way to handle this now.  No need to pursue the problem 
at this point.

This `attempt [break]` debate is really interesting.

I think it uncovered not a bug in the implementation, but provokes 
a discussion on the language semantics.

I guess I'll have to write that up in more detail :)

Thanks for the repeated attempts to explain, Brian!

For me, the work around is:
    error? try [....]
That seems to work in all cases I have tried.


[Ironically, 99% of all the REBOL code I have ever written uses ERROR? 
TRY --  ATTEMPT did not exist when I started REBOL, and my fingers 
have learned to type the idiom. It's only with R3 that I'ved tried 
to update my error handling.....Seems I should stick with my older 
ways for a while...:)]

Ok, I've written up some of my thoughts at http://www.rebol.net/wiki/User_talk:Andreas#Notes_on_Bug.231506_--_on_control_transfer_functions

The gist of it: I think most control transfer functions should be 
unbound globally, and only bound in code executing within their respective 
control transfer handler.