|Version||r3 master||Category||Evaluation||Submitted by||fork|
|Summary||CATCH without /NAME should only catch unnamed throws|
If you do not supply a /NAME to CATCH, it should only CATCH the throws that were not labeled with /NAME. Having an un-qualified CATCH choosing to catch all THROWs regardless of name cannot work for an ecology.
Yet a few rare clients might want a "catch all", even if by definition they cannot know what to do with all possible throws. This would apply to testing code (or some kind of global catch that wants to present a more graceful error message in the case of uncaught throwing in an application). So to cover that need, something that can effectively "catch all" is needed.
CATCH/ALL sounds good for the idiom, but CATCH/ANY is probably more specific and fitting with ANY [...] selection semantics of "any one of these will do". Though it has a minor issue that it would trigger an "incompatible refinement" if used with /NAME. One usually wants to find a way to slip the settings into the same refinement, but there's no particular data type and value that seems appropriate to pass name to mean "everything".
That said... these changes alone don't make a very good long-term-ecology plan. It's not hard to imagine the same word getting used by multiple parties. So being able to use a FUNCTION! or an OBJECT! value as a /NAME might provide a further level of specificity for clients implementing specialized protocols where they want to be sure third parties don't intercept their communication through the stack. Using a WORD! (like BREAK, CONTINUE, QUIT, or EXIT) would be a choice made in rare cases of believing that within the language as a whole, an ecology can come to agreement on what the semantics should be for a throw with that name (and not step on each other).
>> catch [throw 10] == 10 ;-- okay, no name was provided >> catch [throw/name 20 'foo] == 20 ;-- not okay, only things looking for FOO should see it >> catch/all [throw/name 20 'foo] == 20 ;-- special-purpose and probably only wise in test code
|Assigned to||n/a||Fixed in||-||Last Update||17-Aug-2015 00:52|
Yes, absolutely. This in an of itself is a duplicate of #1518. Related CATCH/all is proposed in #1520, and was revised to a `CATCH/name ... TRUE` for catching all named throws. I'll quote the gist of #1520 for easier diving into the discussion:
"We need to rethink CATCH. I think the best model is to have the default be minimal, with CATCH only catching THROW. CATCH/quit would only catch QUIT. CATCH/halt would only catch HALT. CATCH/name word would only catch THROW/name of the EQUIV? word. CATCH/name true would catch all THROW and THROW/name, with whatever words. And you can combine the options in an additive way, with CATCH/quit/halt/name true catching QUIT, HALT, THROW and THROW/name for all names. No other options needed, no potentially conflicting options."
Regarding the "not a good long-term-ecology plan" I also just rediscovered #1744 "Have CATCH /name consider name bindings", which would be in that direction.
Hence, I'm closing this as duplicate.
|17-Aug-2015 00:52||abolka||Status||Modified||submitted => dismissed|
|17-Aug-2015 00:52||abolka||Comment : 0004655||Modified||-|
|16-Aug-2015 23:48||abolka||Comment : 0004655||Added||-|