Am 06.12.2024 um 14:11 schrieb Alan Grunwald:

I'm attempting to get my head around preventing resource leaks, using
try and return. In fact I thought I had understood the mechanisms well
enough to use them and had come up with a structure like this:

proc allocateResources {} {
    set obj1 [Some_mechanism]
    try {
        set obj2 [Some_other_mechanism]
        try {
            do_various_other_stuff
        } on error {message errorDict} {
            $obj2 destroy
            return                                          \
                -code error                                 \
                -errorcode [dict get $errorDict -errorcode] \
                -errorinfo [dict get $errorDict -errorinfo] \
                $message
        }
    } on error {
        $obj1 destroy
        return                                              \
            -code error                                     \
            -errorcode [dict get $errorDict -errorcode]     \
            -errorinfo [dict get $errorDict -errorinfo]     \
            $message
    }

    return [list $obj1 $obj2]
}

If all is well, I expect the caller of allocateResources to destroy the objects when it has finished with them.

There are a couple of areas of this code that I don't completely (?!) understand:

1) I was assuming that if there was an error in do_various_other_stuff
if would be caught by the inner 'on error' clause, which would delete
obj2 and raise another error that would be caught by the outer 'on
error' clause, which would delete obj1. Experiment suggests that this
doesn't happen and the outer 'on error' clause isn't executed.

2) Originally, I wasn't including -errorinfo in the return statements in
the 'on error' clauses, but I found that the stack trace didn't properly identify the line causing the error. Including -errorinfo seems to have
cured that problem.

So,

Q1) Have I misunderstood the way try... works, or is my problem
elsewhere? I realise that I could do away with the nested try...
statement and check whether obj1 and obj2 exist and only destroy them if
they do, but that seems clunky.

Q2) Have I coded the return statements properly to get the error
information to propagate correctly? I have a vague memory of doing it
this way sometime in the past only for some other issue to emerge that I corrected by not using -errorinfo.

Thanks,

Alan

PS For what it's worth, I am using a home-built tcl9.0.0 on Linux Mint.

Alan,
great post. An eventual finally clause is executed in any case, even on
error and on a return within the try case.

For example for a file to be closed on success or error:

proc readfile filename {
# if open fails, there is no resource to close, so keep out of try
set f [open $filename r]
# Now, the file must be closed in any case, so start try
try {
fconfigure $f -encoding utf-8
return [read $f]
} finally {
# close in success case, or in read or fconfigure error case
close $f
}
}

You can also nest:

proc readfile filename {
# if open fails, there is no resource to close, so keep out of try
set f [open $filename r]
# Now, the file must be closed in any case, so start try
try {
fconfigure $f -encoding utf-8
set data [read $f]
# parse data by tdom, which opens another resource
tdom::parse $data handle
try {
return [$handle match abc]
} finally {
$handle destroy
}
} finally {
# close in success case, or in read or fconfigure error case
close $f
}
}

Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 06.12.2024 um 14:11 schrieb Alan Grunwald:

1) I was assuming that if there was an error in do_various_other_stuff
if would be caught by the inner 'on error' clause, which would delete
obj2 and raise another error that would be caught by the outer 'on
error' clause, which would delete obj1. Experiment suggests that this
doesn't happen and the outer 'on error' clause isn't executed.

The return exits the procedure. So, the outer catch is not taken.
Instead, you may use the error command to do so. But keeping the
original stack trace is difficult.

2) Originally, I wasn't including -errorinfo in the return statements in
the 'on error' clauses, but I found that the stack trace didn't properly identify the line causing the error. Including -errorinfo seems to have
cured that problem.

Yes, better use finally.

Q1) Have I misunderstood the way try... works, or is my problem
elsewhere? I realise that I could do away with the nested try...
statement and check whether obj1 and obj2 exist and only destroy them if
they do, but that seems clunky.

I would use the finally and check for a flag. This works also with return.

Q2) Have I coded the return statements properly to get the error
information to propagate correctly? I have a vague memory of doing it
this way sometime in the past only for some other issue to emerge that I corrected by not using -errorinfo.

Better avoid it.

My proposal:

proc allocateResources {} {
set obj1 [Some_mechanism]
try {
set obj2 [Some_other_mechanism]
try {
do_various_other_stuff
# above, resource is cleared, so remove indicator
unset obj2
unset obj1
# this may also go to the end of the procedure, no difference
return [list $res1 $res2]
} finally {
if {[info exists obj2]} {
$obj2 destroy
}
}
} finally {
if {[info exists obj1]} {
$obj1 destroy
}
}
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 06.12.24 um 14:11 schrieb Alan Grunwald:

I'm attempting to get my head around preventing resource leaks, using
try and return.

I haven't worked through your code, but in C++, there is a great idiom
called RAII - things get destroyed when the variable goes out of scope.
This can be simulated for Tcl using a delete trace on the variable.
Using the little utils package from here: https://github.com/BessyHDFViewer/BessyHDFViewer/tree/main/bessyhdfviewer.vfs/lib/SmallUtils

You can do this for files:

proc something {} {
SmallUtils::autofd fd somewfile w
puts $fd "Text comes here"
}
# fd goes out of scope, file is closed

and for any objects that work Tk-like, giving a command back:


SmallUtils::autovar btn button .b -text "Hi"
# will destroy if btn goes out of scope
# by "rename .b {}"


Of course, this is not perfect, it will fail if you copy the variable
somewhere else, but often times it is good enough.

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Alan Grunwald <[email protected]>
| proc allocateResources {} {
| set obj1 [Some_mechanism]
| try {
| set obj2 [Some_other_mechanism]
| try {
| do_various_other_stuff
| } on error {message errorDict} {
| $obj2 destroy
| return \
| -code error \
| -errorcode [dict get $errorDict -errorcode] \
| -errorinfo [dict get $errorDict -errorinfo] \
| $message
| }

As Harald pointed out, 'finally' is the way to go here (even if the
"if exist" is clunky :-).

I just wanted to point out that you could use the errorDict directly, as in

try {
...
} on error {msg opts} {
...
return -options $opts $msg
}

instead of extracting errorinfo and errorcode manually, and if I use
that form, I get the expected behaviour:

proc foo {} {
try {
puts "level 1"
try {
puts "level 2"
error "err level 2"
} on error {msg opts} {
puts "error in level 2"
return -options $opts $msg
}
} on error {msg opts} {
puts "error in level 1"
return -options $opts $msg
}
}

% catch foo
level 1
level 2
error in level 2
error in level 1
1

% set errorInfo
err level 2
while executing
"error "err level 2""
(procedure "foo" line 6)
invoked from within
"foo"

HTH
R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 06.12.2024 um 21:35 schrieb Alan Grunwald:

On 06/12/2024 20:12, Alan Grunwald wrote:

On 06/12/2024 17:59, Ralf Fassel wrote:

* Alan Grunwald <[email protected]>

<all helpful context removed>

Thanks Ralf,

As I pointed out to Harald, deleting the objects in a finally clause
is explicitly not what I want to do since I wish to return them if
there are no errors. I believe that I need to propagate the error
explicitly if I add an on error clause. I'll see what happens if I do
return -options $errorDict $message rather than extracting and
specifying -code, -errorcode and -errorinfo. I guess if would help if
I could recall what issue emerged when I tried doing it that way in
the past, but sadly...

Thank you very much indeed. Modifying my genuine code to use

     return -options $errorDict $message

makes everything work as I originally expected - the resources are
tidied away correctly, and the error is propagated properly.

I'm now a happy bunny, but am slightly troubled by wondering why my
original attempt didn't work. I've had a closer look at the try manpage
and see the statement

"If an exception (i.e. any non-ok result) occurs during the evaluation
of either the handler or the finally clause, the original exception's
status dictionary will be added to the new exception's status dictionary under the -during key."

which I had previously overlooked. I guess that no -during key is
included if I raise the error using -options, but I'm not convinced that there's anything on the try manpage that should make me expect that no
on error handler will be executed if there's a -during key. Granted this
is kind of weird stuff that I wouldn't expect to get right first (or
second or third) time, but I would hope to understand what's going on by
the time I have got it right!

Anyway, thanks again, further explanations would be welcome, but are by
no means essential :-)

Alan

Yes, the magic here is, that the error dict contains "-level 0".
This does not exit the proc and thus, the outer try is also executed.
Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/12/2024 00:02, Alan Grunwald wrote:

On 07/12/2024 13:36, Harald Oehlmann wrote:

Am 06.12.2024 um 21:35 schrieb Alan Grunwald:

On 06/12/2024 20:12, Alan Grunwald wrote:

On 06/12/2024 17:59, Ralf Fassel wrote:

* Alan Grunwald <[email protected]>

<even more helpful context removed>

Yes, the magic here is, that the error dict contains "-level 0".
This does not exit the proc and thus, the outer try is also executed.
Take care,

Thanks Harald,

I have a vague memory that I was including a -level flag on the return statement in the past when "issues emerged". I shall keep my fingers
crossed that I remember this discussion when strange things happen with
this technique in the future.

Alan

I find the "defer" package in Tcllib very useful to achieve RAII in Tcl

https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/defer/defer.md

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)