tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

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

On Tue, 25 Nov 2008 17:56:54 +0200, 
Twylite <tw...@cr...> wrote:

> Sadly it will be some time before I can gain value from this function 
> myself. Not until the third-party libraries I am tied to - which
> require me to parse the (non-localised) result - are updated to
> produce an errorcode. Not until I find enough time on or between
> projects to refactor legacy code (core libraries that I depend on and
> use in pretty much all new utilities and applications) to use
> errorcode rather than (or, for backwards compatibility, in addition
> to) a list structure in the result. Not in places where I need to
> maintain code that allocates & frees more than 2 resources, which can
> be done cleanly using finally callbacks, but otherwise sends you to
> the depths of nested try/finally blocks and you can't see the wood for
> the error-and-cleanup-handling trees.

THIS is the part I've been trying to deal with.

- Support for all current return values, not just one limited view of
reality, so that it's useful NOW, not some time in an unknown future
that may or may not happen.  (That's what happened to errorcode, it was
created before the mechanisms existed to make good use of it, and
it's floundered in obscurity ever since.)

- And for cleaning up those messes of switch and other statements
presently needed to support all kinds of error and result handling.
If done right, it'll be fast and efficient for the simple case.  And
a heck of a lot easier to read and work with in the complex case.

Especially when it's so damn simple trivial to do so much better.


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 49 days,  6:43)

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

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

On Tue, 25 Nov 2008 20:23:35 +0000, 
"Donal K. Fellows" <don...@ma...> wrote:

> Andreas Leitgeb wrote:
>> Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
>> thrown from core appear to have been carefully crafted to be
>> reasonably glob-able.  At this point in time, glob appears like
>> the perfect hammer for the nail, but nails are likely going to
>> change when programmers get more into the habit of creating new
>> errorCodes for their applications, and introducing ambiguities,
>> that could have been avoided by list patterns in the first place.
> So... you're rejecting an admittedly perfect solution for a much more
> complex one because of a possible theoretical problem in the future?
> Words fail me.

I don't think it's been admitted to be perfect.  I believe one of the
the key phrases was "reasonably glob-able", and the other key concept
was that just because it ALMOST fits the present carefully crafted
nails, doesn't mean it will fit the less carefully crafted nails that
will start to appear once the idea of using errorcodes catches on.

Glob on a list is flawed.  It's as simple as that.  And it astounds me
that you can defend the idea of matching a list with at least one piece
of arbitrary text, with glob matching that has no regard for word
boundaries.


Andreas Leitgeb:
> Anyway, all my arguments have been said. Seems like I just failed to
> prevent what I consider a bad thing from happening to Tcl. Alas. <EOD>

While sometimes I go off on a tangent that even I don't expect to be
followed on, and I freely admit that, a good useful implementation of
this will be immediately practical and useful.  We're ALL doing the
kinds of things this command is designed to make easier.  We ALL want
to see good error handling.  We ALL want to be able to get rid of those
annoying and hard to follow if..elseif and catch+switch blocks.  And
[try] has the opportunity to do that in a clean way.

But the way it's being dumbed down to mere triviality, I can't agree
more on this particular sentiment.


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 49 days,  7:01)

Re: [TCLCORE] TIP#234 Status

[Torsten B. <re...@ma...>]

> Is TIP#234 ready to roll (and the implementation acceptably close)? It
> doesn't look far off it to me, but I'm not close enough to the  
> detail to
> be sure.
>
> The primary remaining question is whether the C API is sufficient for
> implementing a PNG reader on top of it in short order. My guess is  
> that
> it is (i.e. we can also do TIP#244) but it'd be nice to have a reality
> check. :-)

I really, really would like to see 234 and 244 in Tcl 8.6 finally. I  
have been using the reference implementations for a longer period now  
and they work for me (on MacOS X and Linux). Just one thing. It has  
been said before, that handling of zip files like reading entries or  
writing them is a simpe task of some Tcl scripting. It would be nice  
if such a tcl script/wrapper could be included in the distribution. I  
don't have it myself but always felt it was missing.

The opinion of a user,

Torsten

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

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

Jeff Hobbs wrote:
> Shall I take the opportunity to push TIP#180 again?  ;)

Thinking about it, I suspect that what we get out of #180 isn't going to
be in 8.6 as we just haven't got the time to finish cooking it before
beta. On the other hand we should push on and get it into tklib (well,
assuming we can now do it in pure Tcl). Like that it can get the public
exposure it needs to get its feature set finalized, and we can see what
*actually* is too slow for Tcl...

It's a shame, as I'd identified #180 as important. Ho hum.

Donal.

Re: [TCLCORE] CFV on small high-prio TIPs (TIP#180)

[Damon C. <da...@tc...>]

> The benefit of external tagging is that any widget can be tagged  
> (even older ones).  This is why I like how tklib tooltip works.   
> Should we add a -tooltip to widgets, or ?

     Ok, then.  So, I've already got a package that does the external  
tagging, and it does a pretty good job of it too.  Should we just push  
that toward tklib and then work on pushing both the tooltip and tags  
stuff into the ::tk namespace for core inclusion?

     I do sort of like the process of vetting an extension through the  
(tk|tcl)libs before core inclusion as it not only works the kinks out  
but gets real-world use and some feedback.

     My current package adds a tag and a configure command to the root  
namespace, but they can just easily go into ::tk or whatever.

::tk::tag add foo .e1 .e2

::tk::tag configure foo -state disabled

etc...

D

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Michael K. <mi...@mu...>]

On the auto-naming of widgets, I've long felt that it's a bit silly we 
have to name them ourselves at all.  I don't care what the widget names 
are, only that I know what they are so I can interact with them.  If I'm 
caring what the actual name is, it probably means I've hardcoded it in 
several places, which is going to make it a hassle to modify the code 
later to restructure/extend the GUI.

I'd prefer to let the parent in the hierarchy do the naming.  Perhaps this 
would largely be a matter just of convention, or perhaps there would be a 
wrapper around Tcl_CreateObjCommand to create widget commands that handle 
this automatically, but I would suggest:

1. A widget creation command (e.g. "frame"), when given no arguments or 
the first argument doesn't start with ".", gets a fully automatic name 
assignment that's a child of "." (or a child of nothing if a toplevel).

e.g.,

set top [toplevel]    ;# -> .toplevel1
set frame [frame]     ;# -> .frame1
set frame [frame]     ;# -> .frame2
set frame [frame .f]  ;# -> .f

2. The parent should be capable of creating widgets and assigning names to 
them in its hierarchy itself.  Maybe this would be done with a subcommand 
specified to that Tcl_CreateObjCommand wrapper 
(Tk_CreateWindowObjCommand?), or maybe something like "." as a subcommand 
is suitably unique and (pardon the pun) on point:

set top [toplevel]           ;# -> .toplevel1
set frame [$top . frame]     ;# -> .toplevel1.frame1
set button [$frame . button] ;# -> .toplevel1.frame1.button1

The wrapper would see that "." is the first argument and treat the second 
argument as a widget creation command (no matter what it is), inserting a 
unique name as its first argument (or, I guess, treat the first two as 
ensembles).

3. Maybe, for cases where you actually do care what the name is, extend 
(1) and (2) a little bit such that if the first argument doesn't start 
with "-" and doesn't contain any dots, then it's a parent-relative name:

set bob [frame bob]         ;# -> .bob
set top [toplevel]          ;# -> .toplevel1
set bob [$top . frame bob]  ;# -> .toplevel1.bob
set ok [$bob . button ok]   ;# -> .toplevel1.bob.ok

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Will D. <wi...@wj...>]

On Nov 25, 2008, at 12:22 PM, Jeff Hobbs wrote:

> Koen Danckaert wrote:
>> Joe English wrote:
>>> TIP#306: NO.
>>>
>>> This one does not play nicely with third-party widget sets or with
>>> megawidget packages.  For the former, it places additional
>>> constraints on widget constructors.  I have no idea how it will
>>> interact with the latter, though I suspect the answer is "not very
>>> well".
>>
>> When the TIP was first discussed on this list, Will Duquette (the
>> author of Snit) said he would like to see it happen.

I vaguely recall that; and Snit does indeed support autonaming of
widgets using the %AUTO% syntax, e.g., [label $win.%AUTO%].  I
don't recall ever looking at the syntax shown in the TIP, though;
and using a single "%" character as the string to be replaced
strikes me as asking for trouble.

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] CFV on small high-prio TIPs (TIP#180)

[Jeff H. <je...@ac...>]

Damon Courtney wrote:
>> Skip -alias, consider -tags (would any known widget conflict at the  
>> widget creation level?).
>>
>> button .b -tags toolbar
>> button .c -tags {toolbar edge}
>> configure toolbar -state disabled
>> ...
>>
>> I simulate this at the higher level now.  It may be asking too much  
>> for 8.6, but possibly worth considering.
> 
>      Yes.  My brain was moving too fast when I posted, but this is  
> exactly what I recommend.  In fact, I use a system I wrote called  
> Tktags that does just this sort of thing.  In fact, it does exactly  
> what you describe here except for the fact that you have to tag the  
> widgets yourself since they don't support a -tags option.

The benefit of external tagging is that any widget can be tagged (even 
older ones).  This is why I like how tklib tooltip works.  Should we add 
a -tooltip to widgets, or ?

Jeff

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Damon C. <da...@tc...>]

> Skip -alias, consider -tags (would any known widget conflict at the  
> widget creation level?).
>
> button .b -tags toolbar
> button .c -tags {toolbar edge}
> configure toolbar -state disabled
> ...
>
> I simulate this at the higher level now.  It may be asking too much  
> for 8.6, but possibly worth considering.

     Yes.  My brain was moving too fast when I posted, but this is  
exactly what I recommend.  In fact, I use a system I wrote called  
Tktags that does just this sort of thing.  In fact, it does exactly  
what you describe here except for the fact that you have to tag the  
widgets yourself since they don't support a -tags option.

Damon

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Jeff H. <je...@ac...>]

Damon Courtney wrote:
>> Let me note that I strongly favor some auto-naming of widgets.  I
>> advocate it and use it in the Perl/Tkx binding that I wrote.  However,
>> it conflicts with years of standard coding style in Tcl, especially  
>> wrt
>> megawidget libraries.  After looking a little further, snidgets  
>> could be
>> made to support this at the base level in one code spot (the advantage
>> of such a system).  However, many older systems spread out there  
>> widget
>> creation among the widgets in a way that is more fragile.
>>
>> Shall I take the opportunity to push TIP#180 again?  ;)
> 
>      I would like to note that not only should TIP 180 support the  
> auto-naming of widgets, I would go one step further and say that TIP  
> 180 should also support some sort of standard, default option on all  
> widgets to create an "alias" of sorts.  Then, I would add a single  
> configure command that handles them.
> 
>      90% of the widgets created in Tk are forgotten in the code  
> because we don't care or need to know anything about them.  This is  
> made even more so by things like -variable and -textvariable which  
> almost let us completely ignore the widget itself.  For the other 10%,  
> we all end up coding some crap like:
> 
> global w
> 
> set w(myEntry) [entry .e]
> $w(myEntry) configure -background blue
> 
>      This is where the new option comes in.  Something like:
> 
> entry .e -alias myEntry
> configure myEntry -background blue
> 
>      Throw in the auto-naming stuff, and you've got yourself a nice  
> way to work with what you care about and lose the rest in the noise.

Skip -alias, consider -tags (would any known widget conflict at the 
widget creation level?).

button .b -tags toolbar
button .c -tags {toolbar edge}
configure toolbar -state disabled
...

I simulate this at the higher level now.  It may be asking too much for 
8.6, but possibly worth considering.

Jeff

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Damon C. <da...@tc...>]

> Let me note that I strongly favor some auto-naming of widgets.  I
> advocate it and use it in the Perl/Tkx binding that I wrote.  However,
> it conflicts with years of standard coding style in Tcl, especially  
> wrt
> megawidget libraries.  After looking a little further, snidgets  
> could be
> made to support this at the base level in one code spot (the advantage
> of such a system).  However, many older systems spread out there  
> widget
> creation among the widgets in a way that is more fragile.
>
> Shall I take the opportunity to push TIP#180 again?  ;)

     I would like to note that not only should TIP 180 support the  
auto-naming of widgets, I would go one step further and say that TIP  
180 should also support some sort of standard, default option on all  
widgets to create an "alias" of sorts.  Then, I would add a single  
configure command that handles them.

     90% of the widgets created in Tk are forgotten in the code  
because we don't care or need to know anything about them.  This is  
made even more so by things like -variable and -textvariable which  
almost let us completely ignore the widget itself.  For the other 10%,  
we all end up coding some crap like:

global w

set w(myEntry) [entry .e]
$w(myEntry) configure -background blue

     This is where the new option comes in.  Something like:

entry .e -alias myEntry
configure myEntry -background blue

     Throw in the auto-naming stuff, and you've got yourself a nice  
way to work with what you care about and lose the rest in the noise.

D

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Jeff H. <je...@ac...>]

Jan Nijtmans wrote:
> 2008/11/25 Jeff Hobbs <je...@ac...>:
>> This is so blatantly wrong with a 30 second glance at what's important
>> that anyone who voted yes deserves a right spanking.  This TIP would
>> break BWidgets, and I don't need to look any further.  The TIP blatantly
>> warns on this issue.  Stop the insanity and poor thinking - you break
>> something as basic as that, you will _not_ make a happy community.
> 
> Please, don't spank me....    ;-)
> 
> I'm not that familiar with BWidgets, but the given arguments
> convince me to change my vote to NO as well.....

Let me note that I strongly favor some auto-naming of widgets.  I 
advocate it and use it in the Perl/Tkx binding that I wrote.  However, 
it conflicts with years of standard coding style in Tcl, especially wrt 
megawidget libraries.  After looking a little further, snidgets could be 
made to support this at the base level in one code spot (the advantage 
of such a system).  However, many older systems spread out there widget 
creation among the widgets in a way that is more fragile.

Shall I take the opportunity to push TIP#180 again?  ;)

Jeff

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Jan N. <jan...@gm...>]

2008/11/25 Jeff Hobbs <je...@ac...>:
> This is so blatantly wrong with a 30 second glance at what's important
> that anyone who voted yes deserves a right spanking.  This TIP would
> break BWidgets, and I don't need to look any further.  The TIP blatantly
> warns on this issue.  Stop the insanity and poor thinking - you break
> something as basic as that, you will _not_ make a happy community.

Please, don't spank me....    ;-)

I'm not that familiar with BWidgets, but the given arguments
convince me to change my vote to NO as well.....

Regards,
         Jan Nijtmans

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 08:23:35PM +0000, Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
> >Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
> >thrown from core appear to have been carefully crafted to be
> >reasonably glob-able.
> So... you're rejecting an admittedly perfect solution for a much more
> complex one because of a possible theoretical problem in the future?

- I don't see it as that *much* more complex.
- I seem to estimate the probability of that future demand
    differently than you. That's just gut-feeling on both sides.
- That it happens to work ok with those errorcodes currently thrown
    from the core does not yet make it perfect.

Anyway, all my arguments have been said. Seems like I just failed to
prevent what I consider a bad thing from happening to Tcl. Alas. <EOD>

Re: [TCLCORE] CFV on small high-prio TIPs (#306) Tk_Uids

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
> Every component of a Tk pathname (i.e. 'a', 'b' and 'c' from '.a.b.c')
> is a Tk_Uid. I've no idea why, but it's how it is; might be related to
> option database handling I suppose. What this means is that if you are
> generating pathnames using a counter you've got a memory leak that you
> cannot plug. (Or at least not short of firing up Tk in a new thread and
> discarding the entire old one!) This means that production code really
> ought instead to be reusing names as much as possible, and yet the
> auto-naming feature was always something that's only really useful for
> production code in the first place.
> 
> Now, I don't know about you, but I reckon that a "production-only"
> feature that production-level code shouldn't use is a bit silly. And
> fixing this is really hard (the Tk_Uid mess is the worst mistake in Tk
> by far, in particular because it is wormed in so deep) and certainly
> won't happen in a minor release.

For reference, Tk_Uids are a compat layer over XIds, unique atoms from a 
time when 128MB of memory was a lot.  They are like refcounting strings 
in a way.  However, Tk's use of them hasn't been the most friendly, and 
indeed downright contradictory (canvas items are Tk_Uids, but are 
monotonically increasing numbers).  Tcl_Objs would be the better fit 
(introduced years later to Tcl), but they can't replace Tk_Uids in 
place.  :-/

Jeff

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

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

Jeff Hobbs wrote:
> This is so blatantly wrong with a 30 second glance at what's important 
> that anyone who voted yes deserves a right spanking.  This TIP would 
> break BWidgets, and I don't need to look any further.  The TIP blatantly 
> warns on this issue.  Stop the insanity and poor thinking - you break 
> something as basic as that, you will _not_ make a happy community.

I've been thinking about this in more depth too, and I've remembered
something about the (rather nasty) guts of Tk that pertains.

Every component of a Tk pathname (i.e. 'a', 'b' and 'c' from '.a.b.c')
is a Tk_Uid. I've no idea why, but it's how it is; might be related to
option database handling I suppose. What this means is that if you are
generating pathnames using a counter you've got a memory leak that you
cannot plug. (Or at least not short of firing up Tk in a new thread and
discarding the entire old one!) This means that production code really
ought instead to be reusing names as much as possible, and yet the
auto-naming feature was always something that's only really useful for
production code in the first place.

Now, I don't know about you, but I reckon that a "production-only"
feature that production-level code shouldn't use is a bit silly. And
fixing this is really hard (the Tk_Uid mess is the worst mistake in Tk
by far, in particular because it is wormed in so deep) and certainly
won't happen in a minor release.

Alas, this means I'm changing my vote.
TIP#306: NO (a double-whammy of problems with megawidgets and Tk_Uid)

I just wish I'd thought about this earlier. :-(

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

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

Andreas Leitgeb wrote:
> Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
> thrown from core appear to have been carefully crafted to be
> reasonably glob-able.  At this point in time, glob appears like
> the perfect hammer for the nail, but nails are likely going to
> change when programmers get more into the habit of creating new
> errorCodes for their applications, and introducing ambiguities,
> that could have been avoided by list patterns in the first place.

So... you're rejecting an admittedly perfect solution for a much more
complex one because of a possible theoretical problem in the future?

Words fail me.

Donal.

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Jeff H. <je...@ac...>]

Koen Danckaert wrote:
> Joe English wrote:
>> TIP#306: NO.
>> 
>> This one does not play nicely with third-party widget sets or with
>> megawidget packages.  For the former, it places additional 
>> constraints on widget constructors.  I have no idea how it will
>> interact with the latter, though I suspect the answer is "not very
>> well".
> 
> The TIP describes how mega-widget packages can support the
> auto-naming scheme. It's really a minor effort.
> 
> When the TIP was first discussed on this list, Will Duquette (the
> author of Snit) said he would like to see it happen.
> 
> Note that the TIP doesn't break compatibility: any application that
> works today (which obviously doesn't use auto-naming), will continue
> to work in the future.

This is so blatantly wrong with a 30 second glance at what's important 
that anyone who voted yes deserves a right spanking.  This TIP would 
break BWidgets, and I don't need to look any further.  The TIP blatantly 
warns on this issue.  Stop the insanity and poor thinking - you break 
something as basic as that, you will _not_ make a happy community.

Jeff

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Joe E. <jen...@fl...>]

Donal K. Fellows wrote:

> The way in which [try] works has got to be this:
>
>    set code [catch $firstbody $msgVar $optVar]
>    set handler [pick handler based on $code [set $msgVar] [set $optVar]]
>    set code2 [catch $handler msg2 opt2]
>    eval $finallybody
>    if {$code2 != 0} {		<== this isn't right
>    ^^^^^^^^^^^^^^^^^^
>       set code $code2; set $msgVar $msg2; set $optVar $opt2
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       # This part (^^^) should be unconditional
>    }
>    return -code $code -options [set $optVar] [set $msgVar]
>
> Or something like that. I've spent as long on that as it took to type.

The result of [try] should be the result of the handler clause,
regardless of whether it succeeds or not.

It should be:

	set code [catch $mainScript value opts]
	if {some clause '{XXX resultVar optsVar} handlerScript' matches} {
	    set $resultVar $value ; set $optsVar $opts
	    set code [catch $handlerScript value opts]
	}
	eval $finallyScript	;# exceptions propagate
	# here: $finallyScript yielded TCL_OK
	return -code $code -options $opts $value


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 07:44:32PM +0200, Twylite wrote:
> >If you think, that embedding switches is a good idiom, then 
> >why not just match the [lindex $errorCode 0] ...

> Because that's so unspecific as to be worthless in most cases.  This 
> would allow you to distinguish between (say) POSIX errors and ARITH 
> errors, but in most cases where you need to branch based on the type of 
> error you are distinguishing between two very similar errors (an IO 
> timeout error versus an IO read error, ...

Ok. Agreed.  That is common enough to justify an idiom
more concise than a nested switch.

Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
thrown from core appear to have been carefully crafted to be
reasonably glob-able.  At this point in time, glob appears like
the perfect hammer for the nail, but nails are likely going to
change when programmers get more into the habit of creating new
errorCodes for their applications, and introducing ambiguities,
that could have been avoided by list patterns in the first place.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Joe E. <jen...@fl...>]

Magentus asked:
> Donal K. Fellows wrote:
> > Subtype descriptors are separate words, as you would know if you'd
> > ever actually looked at them! Here's a couple of real examples:
>
> Could you, then, post right here a formal specification (or link to
> same on the tcl.tk site) of what the errorcode looks like, just as a
> marker point to set this part of the discussion straight.

See return(3tcl), section "RETURN OPTIONS", subsection
"-errorcode".  See also tclvars(3tcl), section 'errorCode'.
See also error(3tcl), section "DESCRIPTION", last paragraph.
Or grep the source code.


> I think without a formal description of what errorcodes actually are,
> this sub-thread has been chasing its own tail just a little.

Yes.  If the participants in the thread better understood
the nature of the problem to be solved we could maybe
get some focus here.


--JE

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

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

Hi,
> If you think, that embedding switches is a good idiom, then 
> why not just match the [lindex $errorCode 0] with a glob or 
> even exactly, and leave further matching to embedded switches?
> Still better than globbing a list, imho.
>   
Because that's so unspecific as to be worthless in most cases.  This 
would allow you to distinguish between (say) POSIX errors and ARITH 
errors, but in most cases where you need to branch based on the type of 
error you are distinguishing between two very similar errors (an IO 
timeout error versus an IO read error, a connect error versus a read 
error versus an authentication error, etc.). 
In addition any third-party package that wants to avoid naming conflicts 
is probably going to use the package name (or company name, or some 
other distinguished identifier) as the most general class of exception, 
which would make matching on [lindex $errorCode 0] virtually useless.

Regards,
Twylite

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 12:57:57PM +0000, Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
> >One point of "try" and it's error-filtering is to make all unhandled
> >exceptions fall through, run the finally block and then get rethrown.

> The way in which [try] works has got to be this:
>   set code [catch $firstbody $msgVar $optVar]
>   set handler [pick handler based on $code [set $msgVar] [set $optVar]]
>   set code2 [catch $handler msg2 opt2]
>   eval $finallybody
>   if {$code2 != 0} {
>      set code $code2; set $msgVar $msg2; set $optVar $opt2
>   }
>   return -code $code -options [set $optVar] [set $msgVar]

Ok, that mutes some doubt I had.  Anyway, nested switches would need
to explicitly re-throw errors not handled.  Not a big issue, but it
shrinks the advantage of [try] against old [catch {...}].

> All that is missing is the code to actually pick the handler script,
> which in turn should be kept simple as well.
> >PS: Is it really that hard to call non-inlined matcher-commands from
> >  generated bytecode?
> 
> It's even more trivial to compile a script. Guess what? You can just put
> that stuff in the script in the first place.

Well, you said, that bytecoding a more advanced matcher/picker would be
exorbitantly more complex, so I wondered if calling out to a separate
command to do the picking wouldn't help to prevent that exponential
explosion of effort bytecoding a saner check.

> So why do we need a generalized matcher architecture?
> Answer: We don't. So why are you developing one?
Here is a little difference between me and Fredderic.

I do not primarily envision all those pluggable handlers, but
I'm very unhappy with using glob-matching on lists(*). Since I do
not see any chance to stop that particular train heading wrong
direction, I do hope for some spare rails that would at least 
allow the next train (8.7 or so) to go in a better direction,
while not derailing this current train on its trip.

*:
I really thought the paradigm was to *reduce* the number of
places where lists are stringified...

If you think, that embedding switches is a good idiom, then 
why not just match the [lindex $errorCode 0] with a glob or 
even exactly, and leave further matching to embedded switches?
Still better than globbing a list, imho.

> Not "astronomer", "astronaut". With reference to
>  http://www.joelonsoftware.com/articles/fog0000000018.html
Ok, this definition doesn't suit me that well.  I may lose
ground with some visions, but hardly ever for high abstractions.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Colin M. <co...@ch...>]

Magentus wrote:
>     try script
>     as {vars}
>     handler ?-- errorcode-pattern? body
>     return ?-- returnvalue-patten? body
>     on {code ?-- returnvalue-pattern?} body
>     finally body
>   


With all due respect, that's a hairy nightmare and I wouldn't use it on 
principle (the principle is that anything with *that* many arguments is 
too hard to keep in my head while coding.)

Is there really no way you can simplify it to do one thing, that's hard 
to do without it, and do it well?

Just, perhaps, [try {} finally {}] ... that's simple, even I can 
remember that one, and have a reasonable guess at what it might do, and 
anything more complex occurs (say) in the 'finally' block.

(Oh, and before anyone asks, I don't think 
try/as/handler/return/on/finally would benefit from NULLs)

Colin.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

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

Hi,
> And also:
>    http://www.acmqueue.org/modules.php?pa=showpage&pid=505&name=Content
>
> I hold architecture astronautics in contempt. Reminds me too much of
> work and of how projects can go wrong for failing to focus on critical
> details.
>   
Very well.  Here is the proposal:

--
  try tscript ?as {emvar ?optsvar?}? ?handler ...? finally fscript
where handler is one of:
  on code hscript
  trap pattern hscript

code may be any integer or the magic values ok, return, error, break, 
continue.
trap handles only return code error where pattern is a glob match 
against the -errorcode.
only one handler's hscript is executed, and it will be the first 
matching handler in left-to-right order.  If the hscript is the literal 
"-" then the hscript for the next handler (in left to right order) shall 
be used. The result of executing the hscript is the result of the [try].
exceptions in the hscript replace the original exception and propagate 
(no further handlers are searched). 
any unhandled exception is propagated.
fscript is executed regardless of success or exceptions, and is done 
after the handler (if any) is executed.  Exceptions in the fscript 
replace the original (or hscript) exception and propagate, otherwise the 
result of fscript is discarded.
If an exception is replaced (by one in hscript and/or fscript) then the 
new exception shall introduce a field to its options dict the contains 
all details of the original exception (forming a chain of exceptions).
emvar and optsvar, if specified, will always be populated with details 
of the outcome of tscript.

To complement [try] there shall also be a new command [throw] to 
encourage the use of the trap facility.

  throw type message
where type is a list that will become the -errorcode.  throw is 
equivalent to [error $message {} $type]
--

Opportunity for future extension:
- If the handlers presented are shown to be insufficient for common use 
cases, it will be possibly to add more handler types (using keywords 
other than "on", "trap"). 
- If the variables that capture exception information are insufficient, 
additional vars can be added to the "as" list without affecting 
compatibility
- If all else fails, options can be added between try and tscript (as 
with switch & friends).

Sample implementation to follow.

Sadly it will be some time before I can gain value from this function 
myself.
Not until the third-party libraries I am tied to - which require me to 
parse the (non-localised) result - are updated to produce an errorcode.
Not until I find enough time on or between projects to refactor legacy 
code (core libraries that I depend on and use in pretty much all new 
utilities and applications) to use errorcode rather than (or, for 
backwards compatibility, in addition to) a list structure in the result.
Not in places where I need to maintain code that allocates & frees more 
than 2 resources, which can be done cleanly using finally callbacks, but 
otherwise sends you to the depths of nested try/finally blocks and you 
can't see the wood for the error-and-cleanup-handling trees.

But hey, I'm an astronaut, what would I know about this real-world stuff?

Twylite