From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30864 invoked by alias); 4 Aug 2008 19:50:31 -0000 Received: (qmail 30845 invoked by uid 22791); 4 Aug 2008 19:50:30 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 19:49:52 +0000 Received: from HOME-C4E4A596F7 ([77.126.7.152]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K5300B4EDPNZXA0@i-mtaout7.012.net.il> for gdb-patches@sources.redhat.com; Mon, 04 Aug 2008 22:49:00 +0300 (IDT) Date: Mon, 04 Aug 2008 19:50:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: <20080804121451.GA13640@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <20080726173508.GA16470@caradoc.them.org> <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> X-IsSubscribed: yes 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 X-SW-Source: 2008-08/txt/msg00064.txt.bz2 > Date: Mon, 4 Aug 2008 08:14:52 -0400 > From: Daniel Jacobowitz > Cc: Thiago Jung Bauermann , tromey@redhat.com, gdb-patches@sources.redhat.com > > On Mon, Aug 04, 2008 at 06:20:47AM +0300, Eli Zaretskii wrote: > > I think what I suggested is still valid: no matter how the exception > > is caught, it will still terminate the current command, won't it? > > And, btw, do we actually have examples of such non-default exception > > handling in GDB? > > About half the times that TRY_CATCH or catch_exception / catch_error > are used, we handle an exception in a more specific way. Some are for > cleanups, but many continue after e.g. a memory read error. The > current action is terminated, but the action may be just part of > a command. Okay, how about this, then: When executing the @code{python} command, Python exceptions uncaught within the Python code are translated to calls to @value{GDBN} error-reporting mechanism. If the command that called @code{python} does not handle the error, @value{GDBN} will terminate it and print an error message containing the Python exception name, the associated value, and the Python call stack backtrace at the point where the exception was raised. Example: