Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Harald Oehlmann <wortkarg3@yahoo.com>
Newsgroups: comp.lang.tcl
Subject: Re: try... query
Date: Fri, 6 Dec 2024 15:22:28 +0100
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <viv1b3$26vb1$3@dont-email.me>
References: <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 15:22:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c2499876a6e605d2c54b97c97dfe8e81";
	logging-data="2325857"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1xBkiotj4DiDcz3f0m1/B"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JSlq9RQwxY1Ke3ecSUy498jVo+U=
In-Reply-To: <viut96$2bm0b$1@dont-email.me>
Content-Language: en-GB
Bytes: 3045

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