Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Alan Grunwald <nospam.nurdglaw@gmail.com>
Newsgroups: comp.lang.tcl
Subject: try... query
Date: Fri, 6 Dec 2024 13:11:59 +0000
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <viut96$2bm0b$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 06 Dec 2024 14:13:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="4a6c095b43fc6c58b36b95c87ce9625a";
	logging-data="2480139"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OMtNHTuYFGt3IdPMpDQZvUtzWawKCMv8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hOIXMSQlHGAk4BpIsZEbONxz4gM=
Content-Language: en-US
Bytes: 3390

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.