Re: catch replacing useful errorInfo

On Aug 31, 7:45 am, Donald G Porter <d...@xxxxxxxx> wrote:
Scrolling back to pick up a couple other points.

tom.rmadilo wrote:
2. This one is difficult to give an example for, maybe this has been
fixed, but the idea is that the body of catch has to be compiled, and
this can fail.

The addition of bytecode compiling in 8.0 was a big step, and it did
take some time to shake *all* the bugs out (some might say we're still
shaking). My guess is that you ran into something ugly like Tcl Bug
705406, and that's made you shy about using [catch]. That bug was a
bad one, but it's fixed now.

I think this explains why I couldn't seem to reproduce this behavior.
I remember it, but wasn't able to force it to happen in an example.
Very nasty, good it is gone.

5. ... getting all this to work requires full use
of catch, error and return. So using catch is not bad style or bad
programming, it is a big tool which requires a lot of care to apply
correctly,

Developments in Tcl 8.5 should have improved this a fair bit. Take
a look at the updated documentation and TIP 90 for some examples.

http://tip.tcl.tk/90

This is simply amazing! My original example accomplishes the same
thing in 8.4, but is much more ugly and prone to bad programming
style. It appears that these new features will allow the caller to
handle or not any exceptional results, so the proc interface remains
clean.

proc doSomething {} {
set resource [allocate]
catch {
# Arbitrarily long script of operations
} result options
deallocate $resource
return -options $options $result
}

Obviously none of my comments or examples in this thread apply to 8.5.


.