From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5927 invoked by alias); 27 Jun 2017 19:08:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5907 invoked by uid 89); 27 Jun 2017 19:08:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=eek, management X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Jun 2017 19:08:36 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B76087F3FE; Tue, 27 Jun 2017 19:08:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B76087F3FE Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B76087F3FE Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5DD5178C36; Tue, 27 Jun 2017 19:08:33 +0000 (UTC) Subject: Re: [RFA 09/10] Return EXT_LANG_BT_ERROR in one more spot in py-framefilter.c To: Tom Tromey , gdb-patches@sourceware.org References: <20170425194113.17862-1-tom@tromey.com> <20170425194113.17862-10-tom@tromey.com> From: Pedro Alves Message-ID: <86211a34-85c4-312f-37dd-6541219d0e6b@redhat.com> Date: Tue, 27 Jun 2017 19:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00748.txt.bz2 On 06/27/2017 06:31 PM, Pedro Alves wrote: > On 04/25/2017 08:41 PM, Tom Tromey wrote: >> While reading py-framefilter.c, I found one spot where an exception >> could be caught but then not be turned into EXT_LANG_BT_ERROR. This >> patch fixes this spot. > > Eek. LGTM. > > I wonder whether we could wrap the TRY/CATCHes in something > that would do this exception handling systematically/automatically. > Maybe: > > template > enum ext_lang_bt_status success > try_py (Func &&f) > { > TRY > { > f (); > } > CATCH (except, RETURN_MASK_ALL) > { > gdbpy_convert_exception (except); > return EXT_LANG_BT_ERROR; > } > END_CATCH > > return EXT_LANG_BT_OK; > } > > Used like: > > return try_py ([] > { > // old body of TRY goes here. > }); I gave this a quick try, but it looked ugly, not much of an improvement. Maybe with statement expressions or macros it'd look better... The way to go is actually probably to follow up on the idea of patch #6, and actually just remove the TRY/CATCHes, letting the exceptions propagate and catch them somewhere higher up the chain. Other than marshalling C++ exceptions near Python/ext_lang entry point code, is there another reason we need all the TRY/CATCHes? [assuming local resource management has been RAII-fied.] Thanks, Pedro Alves