From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 15D323858406 for ; Fri, 19 Nov 2021 20:53:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15D323858406 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 47AAD212CB; Fri, 19 Nov 2021 20:53:17 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 31DB913B53; Fri, 19 Nov 2021 20:53:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id QJQWC70OmGEjFQAAMHmgww (envelope-from ); Fri, 19 Nov 2021 20:53:17 +0000 Subject: Re: [PATCH 1/8] [gdb/testsuite] Factor out proc finally To: Pedro Alves , gdb-patches@sourceware.org References: <20211025103000.1237-1-tdevries@suse.de> From: Tom de Vries Message-ID: <4e25c903-4844-13c3-63ff-03574ace37dc@suse.de> Date: Fri, 19 Nov 2021 21:53:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 20:53:19 -0000 On 11/19/21 8:33 PM, Pedro Alves wrote: > On 2021-10-25 11:29, Tom de Vries via Gdb-patches wrote: >> There's a common pattern in the tcl procs to run cleanup code, emulating >> the 'finally' functionality: >> ... >> set code [catch { >> # Try. >> ... >> } result] >> >> # Finally. >> ... >> >> # Return as appropriate. >> if { $code == 1 } { >> global errorInfo errorCode >> return -code error -errorinfo $errorInfo -errorcode $errorCode $result >> >> } elseif { $code > 1 } { >> return -code $code $result >> } >> >> $result >> ... >> >> Factor this out into a new proc 'finally', such that we can simply write: >> ... >> finally { >> # Try. >> ... >> } { >> # Finally. >> ... >> } > > > The position of the "finally" seems super surprising to me. I'd expect something like one of > the below: > > try { > # Try. > } finally { > # Finally. > } > > try { > # Try. > } { > # Finally. > } > > try_finally { > # Try. > } { > # Finally. > } > > > Can we just use standard try/finally, though? > > https://wiki.tcl-lang.org/page/try > > It looks exactly like the first example I give above. > > It's available starting with TCL 8.6. We could add some simple fallback implementation > similar to yours that only supports try/except if necessary, I think. > Well, the problem is that we have test-cases that rely on non-standard 'finally' behaviour. I've tried to explain the difference to the standard 'finally' implementation in the submission, see the notes. So yes, we could use the tcl finally, if we fix those test-cases first. Thanks, - Tom