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.

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

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
}
}
}

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

* Alan Grunwald <nospam.nurdglaw@gmail.com>
| 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'

On 06/12/2024 13:42, Harald Oehlmann wrote:
> 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.

Thank you.

.. 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
>     }
> }

Errr. No.

I had carefully crafted my example to demonstrate that deleting objects
in a finally clause would not be appropriate, since if there is no error
the "normal" return statement will return the two objects and the caller
of allocateResources will be responsible for deleting them.

Thank you very much for your examples of different use cases. Is it
possible to achieve what I would like? Is it possible with something
other than using a single try statement that has an on error clause like

if {[info exists obj1] && $obj1 in [info commands $obj1]} {
$obj1 destroy
}
if {[info exists obj2] && $obj2 in [info commands $obj2]} {
$obj2 destroy
}

or does this represent minimal clunkiness?

On 06/12/2024 17:59, Ralf Fassel wrote:
> * Alan Grunwald <nospam.nurdglaw@gmail.com>
> | 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'

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...

Alan

On 06/12/2024 20:12, Alan Grunwald wrote:
> On 06/12/2024 17:59, Ralf Fassel wrote:
>> * Alan Grunwald <nospam.nurdglaw@gmail.com>
<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

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 <nospam.nurdglaw@gmail.com>
> <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

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 <nospam.nurdglaw@gmail.com>

<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

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 <nospam.nurdglaw@gmail.com>
>
> <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