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

[Magentus <mag...@gm...>]

On Tue, 02 Dec 2008 01:05:45 +0200, 
Twylite <tw...@cr...> wrote:

> Thanks Joe,
>> Also also: re: "trap" clauses doing a glob match or
>> a list prefix match: either way sounds OK to me.
>> I have a slight preference for list prefix match,
>> but glob matching is also OK.
> So far the opinion seems to be that a list prefix is too limited, and
> a list pattern match (per element glob) is too difficult and has no
> existing reference.

That's been a short-coming with glob matching all alone, and something
I tried to address in a pluggable manner as a side-issue of my proposal.

Just because it has no existing reference is no reason to brush it
under the rug and pretend it doesn't exist.


> List prefixes are limited because they don't allow an errorcode to
> represent multiple dimensions. e.g. A media streaming error could be
> both an AudioException and an IOException, and different users of
> your media library may want to treat the error in different ways (a
> stream ripper is more concerned with IOExceptions, whereas a music
> player is probably more concerned with all types of AudioException
> (io, encoding, etc) ).  A list prefix matcher could cope with Java's
> single inheritance model, but not with the exception support
> available to (say) C++.

I dealt with that in my proposal, too.  You're not going to shoe-horn
C++ exceptions into any kind of string match.  That's why my proposal
split the handler into three keywords, two being common use cases, and
the third being a catch-all for everything else.  The idea also, was
that entirely new error paradigns could be added down the road, such as
OO exception handling.

Further, not all exceptions are errors.  A piece of information may or
may not be available yet.  If it is, then a result can be produced.  If
it isn't, then some information can be returned and presented to the
user.  That can readily be reflected by an exception, but is not an
error.  It is in that same line of reasoning that I pushed for matching
on OK return values also.


>> we don't ever want to see
>>     [try { ... } trap -match regexp "..." { ... }]
> No, no we don't ;)

Why the heck not?  (I believe the very next message also says basically
the same)


> The intended manner for extending [try] is by adding new handler
> keywords (if the existing ones are not handling the required use
> cases).

As I proposed very early on in the piece.  That doesn't mean you want
to swamp [try] with 1001 handler keywords for every possible error
source and string match combination.

[try] keywords should deal exclusively with the form that the error
takes, and a string match option should take care of matching against
the actual content of the error, if doing so even makes any sense for
that error form.


And all I'm reading is people complaining that the current proposal
won't do this, and won't do that, that my proposal answers cleanly.
Sounds like a case of "this is my party" to me.


-- 
Fredderic

You would if you could, but you can't so you won't.

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 2 days, 20:29)