From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28617 invoked by alias); 5 Aug 2008 18:50:02 -0000 Received: (qmail 28566 invoked by uid 22791); 5 Aug 2008 18:50:01 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Aug 2008 18:49:22 +0000 Received: from HOME-C4E4A596F7 ([77.126.7.152]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K55007M05MKJHA0@i_mtaout3.012.net.il> for gdb-patches@sources.redhat.com; Tue, 05 Aug 2008 21:49:33 +0300 (IDT) Date: Tue, 05 Aug 2008 18: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: <20080805182305.GA6840@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: <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> <20080805020754.GA17244@caradoc.them.org> <20080805121908.GA17219@caradoc.them.org> <20080805182305.GA6840@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/msg00083.txt.bz2 > Date: Tue, 5 Aug 2008 14:23:05 -0400 > From: Daniel Jacobowitz > Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com > > 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 > operation 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: As I said, I don't see the (marginal, IMO) case of Python invoked by something other than a command worth obscuring this already quite complicated description. So I suggest to reinstate "command" in the second sentence, since this is the most frequent situation users will see. But if you really want to be rigorous, I will claim that "GDB does not handle the error" is inaccurate as well because what is described afterwards _is_ handling the error. So we would need to make that sentence even more complicated, etc. etc. All this for a situation that most users will never care about. I think it's a wrong balance, but if you still insist on doing it, go ahead and install your version; I don't see a sense in arguing about this nit any longer.