From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2348 invoked by alias); 5 Aug 2008 12:19:50 -0000 Received: (qmail 2340 invoked by uid 22791); 5 Aug 2008 12:19:49 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Aug 2008 12:19:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2FC36983EF; Tue, 5 Aug 2008 12:19:09 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E28CA983A9; Tue, 5 Aug 2008 12:19:08 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KQLVM-0004Ye-CI; Tue, 05 Aug 2008 08:19:08 -0400 Date: Tue, 05 Aug 2008 12:19:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support Message-ID: <20080805121908.GA17219@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com References: <20080726173508.GA16470@caradoc.them.org> <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> <20080805020754.GA17244@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00074.txt.bz2 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? 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. -- Daniel Jacobowitz CodeSourcery