From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6742 invoked by alias); 5 Aug 2008 18:10:47 -0000 Received: (qmail 6731 invoked by uid 22791); 5 Aug 2008 18:10:46 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Aug 2008 18:10:07 +0000 Received: from HOME-C4E4A596F7 ([77.126.7.152]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K55008113T5TW80@i_mtaout5.012.net.il> for gdb-patches@sources.redhat.com; Tue, 05 Aug 2008 21:10:18 +0300 (IDT) Date: Tue, 05 Aug 2008 18:10:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: <20080805121908.GA17219@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: <20080726173508.GA16470@caradoc.them.org> <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> <20080805020754.GA17244@caradoc.them.org> <20080805121908.GA17219@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/msg00079.txt.bz2 > Date: Tue, 5 Aug 2008 08:19:08 -0400 > From: Daniel Jacobowitz > Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com > > On Tue, Aug 05, 2008 at 06:30:51AM +0300, Eli Zaretskii wrote: > > > So that gives me a paragraph like this, which I think is accurate. > > > Does this look OK to you? > > > > > > When executing Python code, uncaught Python exceptions are translated > > > to calls to the @value{GDBN} error-reporting mechanism. If > > > @value{GDBN} does not handle the error, it will terminate the current > > > command 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: > > > > I'm not sure this change is for the best: you've eliminated only one > > of the two uses of "command" in this text, which just obfuscates the > > text a little (what is it exactly in GDB that does not handle the > > error, and if it isn't a command that invoked "python", why do we > > terminate a command?). > > Is s/command/operation/ acceptable? No objections, but what problem would that solve? > If any part of GDB handles the error, the error is swallowed. > Otherwise it drifts upwards through the call stack, terminating > function calls as it goes. It's always caught if it reaches the main > command loop, but there are lots of other places too. Yes, I know, but again: how does this help to make the above passage right?