REBOL3 tracker
  0.9.12 beta
Ticket #0001518 User: anonymous

Project:



rss
TypeBug Statussubmitted Date12-Mar-2010 20:01
Versionalpha 97 CategoryNative Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary CATCH without /name catches THROW/name
Description THROW/name needs to be able to escape through CATCH without the corresponding name. Otherwise there's no point to the /name option. If there is no corresponding CATCH/name, it should be treated like an error, same as an uncaught THROW.

If R2 has the same behavior, it should be fixed there too.

See also #1520.
Example code
>> catch/name [catch [throw/name 1 'foo] 2] 'foo
== 2  ; should be 1
>> catch/name [catch/name [throw/name 1 'foo] 'bar 2] 'foo
== 1  ; this is right

Assigned ton/a Fixed in- Last Update23-Mar-2013 02:09


Comments
(0002093)
Ladislav
12-Mar-2010 20:31

I think that the described behaviour is not a bug.

In my opinion it is good that all THROWs can be caught in one place.

My only objection is that the CATCH function can catch named throws, but it cannot rethrow them when needed.

Moreover, the /NAME variants of CATCH/THROW are used rarely signaling they are not as useful as they were intended to be.
(0002094)
BrianH
12-Mar-2010 22:05

We need a CATCH/all (to solve the problem you mention, see #1520), but we definitely *don't* want CATCH without an option to catch THROW/name. And I use the /name option often, but would use it more often if it worked properly.

It would be better to have CATCH always act like CATCH/name, but with some non-word internal value like #[none] if the /name option is not provided. Non-word so you can't provide the default value as a /name parameter. It wouldn't surprise me if this wasn't the current implementation, but it's the catching policy that is an issue.
(0002095)
abolka
12-Mar-2010 22:40

R2 has the same behaviour.
(0002096)
BrianH
12-Mar-2010 23:00

And when CureCode gets a project for R2, I'll report it there as well. Though it might not be fixable for R2 because of backwards compatibility. Not a problem for R3, fortunately.
(0002812)
BrianH
5-Nov-2010 23:12

Note: This is part one of a two-part request to change the default behavior of CATCH to what users of THROW/name would expect. We are *not* getting rid of the ability to catch all THROWs, named or not. Especially since there are a few people like Ladislav who need that ability to write things like test framework engines.

The purpose of this ticket is to change the *default* behavior so that THROW/name will be more useful to more people. But we won't get completely get rid of the ability to catch all throws, we will just make it *optional*. Together, #1518, #1520, #1742 and #1743 will make it possible to catch everything, but make everything useful to the greatest number of people by default.

#1744 is a related issue that is meant to make all of the rest of this final - with that, all subsequent request for new control functions can be implemented in mezzanine with THROW/name instead. And then we won't need to worry about catching stuff, #1520, #1742 and #1743 will catch it all in combination. No more arms race. No more genius-level programming needed to do basic language extensions.
(0002846)
maxim
12-Nov-2010 08:31

I agree that by default CATCH shouldn't trap THROW/name.

the reason is simple, it makes it much more useful and adds a combination which cannot be imitated right now. Many tools could use /name to trap only their things, while remaining transparent to other catches.

With /name implemented as is suggested here, we can create many new control mechanisms which are focused to specific API and tool-set needs. for example it would be trivial to make a for-* loop which has its own specific master like break instruction which skips all intermediate loops without affecting any catch code within the loop itself.

something like:

interrupt: does [throw/name 'interrupt]
interruptible: func [block] [  catch/name do block 'interrupt   ]
blocks: [
  [quit print 1] ; quit is catched by foreach
  [interrupt print 2] ; this jumps over the foreach up to interruptible
  [print 3]
]
interruptible [
   foreach blk blocks [
      catch/quit [do blk]
   ]
]
(0003416)
Ladislav
30-Jan-2013 09:10

"the reason is simple, it makes it much more useful and adds a combination which cannot be imitated right now." - that is not true, in fact. To imitate such a behaviour you can just use

catch/name [...] 'unnamed
(0003724)
BrianH
23-Mar-2013 02:09

Ladislav, that will only work in noone else has a CATCH without /name in any intermediate code. When you are writing library code you can control the end points but not the intermediate code path. So, in order to use catch/name [...] 'unnamed as a workaround in code you didn't write you would need to replace the CATCH and THROW that code uses with a wrapper that calls CATCH and THROW with /name every time internally. And then you better hope #1744 gets implemented, or CATCH and THROW without name will cease to work properly. And this is all for a feature that we should have by default.

Date User Field Action Change
23-Mar-2013 16:51 Ladislav Comment : 0002093 Modified -
23-Mar-2013 16:49 Ladislav Comment : 0002093 Modified -
23-Mar-2013 16:48 Ladislav Comment : 0002093 Modified -
23-Mar-2013 02:32 BrianH Comment : 0003724 Modified -
23-Mar-2013 02:09 BrianH Comment : 0003724 Added -
30-Jan-2013 09:10 Ladislav Comment : 0003416 Added -
30-Jan-2013 09:03 Ladislav Comment : 0002093 Modified -
30-Jan-2013 09:02 Ladislav Comment : 0002093 Modified -
30-Jan-2013 09:02 Ladislav Comment : 0002093 Modified -
30-Jan-2013 09:01 Ladislav Comment : 0002093 Modified -
12-Nov-2010 08:32 maxim Comment : 0002846 Modified -
12-Nov-2010 08:31 maxim Comment : 0002846 Added -
5-Nov-2010 23:12 BrianH Comment : 0002812 Added -
12-Mar-2010 23:12 BrianH Comment : 0002096 Modified -
12-Mar-2010 23:01 BrianH Description Modified -
12-Mar-2010 23:00 BrianH Comment : 0002094 Modified -
12-Mar-2010 23:00 BrianH Comment : 0002096 Added -
12-Mar-2010 22:40 abolka Comment : 0002095 Added -
12-Mar-2010 22:05 BrianH Comment : 0002094 Added -
12-Mar-2010 20:31 Ladislav Comment : 0002093 Added -
12-Mar-2010 20:24 BrianH Code Modified -
12-Mar-2010 20:03 BrianH Code Modified -
12-Mar-2010 20:03 BrianH Description Modified -
12-Mar-2010 20:01 BrianH Ticket Added -