Type | Bug | Status | submitted | Date | 12-Mar-2010 20:01 |
---|---|---|---|---|---|
Version | alpha 97 | Category | Native | Submitted by | BrianH |
Platform | All | Severity | minor | Priority | normal |
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 to | n/a | Fixed in | - | Last Update | 23-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 | - |