Re: [TCLCORE] TIP #329 [try] updated

[Twylite <tw...@cr...>]

Hi,
>> In all seriousness, I've already encountered some situations that lead 
>> me to believe there will be teething problems, and some careful thinking 
>> about what conventions to adopt for -errorcode.
>>     
> What none of this does is make good error design easy, and people mess
> it up in other languages too.
Of course :)  I was just pointing out that this approach is going to 
have some limitations and surprises.  In general it is ridiculously easy 
to extend code written in Tcl while maintaining backwards compatibility 
- we regularly refactor the guts of packages to improve functionality 
while providing backwards-compatible behaviour with safe defaults.  Even 
return values can be made backwards compatible using a facade that maps 
the original interface onto a new more powerful function.  Errorcodes 
based on glob matching cannot always be extended in this manner (while 
maintaining backwards compatibility); you need to get some aspect of the 
design right up front, both in how the exception is thrown and how it is 
caught.  So, as I said, teething problems.  And I imaging an ongoing 
cause of questions to c.l.t as new developers encounter this sort of 
thing and grapple with it.
> want the [try] command to be bytecoded, it's definitely the case that
> exact matching of errorcodes is not enough, and it's definitely the case
> that we already have glob matching machinery in the bytecode engine but
> not anything more complex. Going beyond requires *much* more work.
>   
List prefix matching?
> (Myself, I'd prefer to translate the major value from the hardware
> coprocessor in your example into some kind of name token as well as
> putting the number in there afterwards. But that's because I prefer to
> not expose magic numbers to Tcl code, and it's getting into stuff that's
> wildly off-topic...)
>   
While this addresses the confusion between two similar errorcodes ("ABC 
4" vs "ABC 42") ...
(1) The potential for confusion is still there and not necessarily 
obvious to the person naming the errors.  A quick analysis of the WIN32 
platform SDK shows 42 error names that are also prefixes of other error 
names (e.g. ERROR_INVALID_HANDLE is a prefix of 
ERROR_INVALID_HANDLE_STATE, ERROR_INVALID_DATA is a prefix of 
ERROR_INVALID_DATATYPE).  Trapping "WIN32 ERROR_INVALID_HANDLE*" may 
trap errors you don't want, and "WIN32 ERROR_INVALID_HANDLE *" won't 
work unless the code throwing the error ensures that there is a trailing 
space or subclass (like "NONE").
(2) If you trap using an exact match rather than a prefix match, your 
trap will no longer work if the errorcode is subclassed or otherwise 
extended.  So it is not safe to trap using exact matching.  e.g. If I 
extend my Win32 binding to include the numeric code ("WIN32 
ERROR_INVALID_HANDLE 6" instead of "WIN32 ERROR_INVALID_HANDLE") any 
traps that use exact matching will no longer function as intended.

>> A glob against errorcode doesn't work like an OO is-a relationship.
>>     
> True, but is it "good enough"? We don't need perfection immediately.
>   
Dunno :)  The examples/problems given above tell me that an exact match 
is almost never desirable, and a (list) prefix match is likely to be the 
most common case.  A true list prefix match (not a glob match on a 
string) gives functionality equivalent to catching exceptions by class 
in a single-inheritance OO model (e.g. Java).  A glob match can 
potentially do more, but at the risk of handling yourself enough rope to 
get it wrong a lot of the time.

I'll see what else experience brings out today...

Regards,
Twylite