Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

[Donal K. F. <don...@ma...>]

Neil Madden wrote:
> Firstly, "onerror" and "except" seem like bad names to me. "except" in
> particular would imply that the following error case *isn't* handled (as
> in "catch everything *except* for these..."), which is just confusing. I 
> also have some problems with the usage. I'd prefer to see something like:

I'm going to disagree with you...

>      } else {
>         ...
>      } catch error {vars...} {
>         ...
>      } catch continue {...} {
>         ...
>      } catch -1200 {...} {
>         ...

Those 'catch' clauses cause me problems. You seem to me to be wanting to
make a single clause for catching all errors, but to me one of the main
points about [try] is that it gets away from that. It's a main point
because it makes a real difference for elevating code above the level of
the current [catch] capabilities. Right now, doing code to handle
different errors with [catch] is fairly ugly (though easier than before
TIP#90) and your proposal doesn't help that much. Twylite's proposal is
more workable, as it matches errors against the errorcode and everything
else against the result code (I suppose we could allow a * for anything
in the spec part of the 'except' matcher, but it's not clear to me why
you'd want to).

> (I'm happy to use "on" or "handle" instead of "catch").

That's more of a bikeshed issue.

> Certainly, I think dispatch based on the return code/exception type
> should be at least as easy as based on errorCode -- I can think of lots
> of examples of Tcl code that does this, but almost none that actually
> looks at errorCode. You might think that is unfortunate, and that it
> would be better if more people made use of errorCode, but that's the way
> it is.

That's why 'onerror' and 'except' clauses are both needed. (The names
could be better, but arguing syntax when the semantics still need fixing
is wasteful.)

> Support for existing, widely-used idioms, should be as much, if
> not more, important than promoting lesser-used alternatives. In fact,
> I'd leave out entirely the glob-matching on errorCode, and let people do
> this with [switch] if they want it:

No. That's advocating a lack of vision. If we make it *easy* to trap
specific errors by errcode, people will do so. People don't now because
it is too hard.

> To me, this strikes a good balance between flexibility and simplicity.
> In particular, it leaves pattern matching to existing commands [switch],
> [regexp] and so on. So, for instance we won't down the line have people
> asking for catch -regexp or catch -nocase and so on (which would almost
> certainly happen if errorCode usage does take on).

What is proposed can still permit such things with an enclosed [switch]
as they can still match all errorcodes with *, but it should encourage
people to make better use of what we've got.

Donal.