From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21543 invoked by alias); 26 Jul 2008 19:18:59 -0000 Received: (qmail 21532 invoked by uid 22791); 26 Jul 2008 19:18:58 -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; Sat, 26 Jul 2008 19:18:39 +0000 Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4M00IHJO8ORD50@i_mtaout5.012.net.il> for gdb-patches@sources.redhat.com; Sat, 26 Jul 2008 22:17:12 +0300 (IDT) Date: Sat, 26 Jul 2008 19:18:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: X-012-Sender: halo1@inter.net.il To: tromey@redhat.com Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <20080726173508.GA16470@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-07/txt/msg00496.txt.bz2 > From: Tom Tromey > Date: Sat, 26 Jul 2008 11:42:12 -0600 > > >>>>> "Daniel" == Daniel Jacobowitz writes: > > Daniel> No need to talk about the internal meaning for that part - we can just > Daniel> talk about interrupting operations with Control-C. I'm not sure how > Daniel> to explain "other exceptions"; just "other error conditions"? > > How about this? > > When executing the @code{python} command, uncaught Python exceptions > are translated to calls to @value{GDBN}'s @code{error} function. > Conversely, @value{GDBN} exceptions are converted to Python > exceptions. In particular, a user interrupt (via @kbd{C-c} or by > typing @kbd{q} at a pagination prompt) is translated to a Python > @code{KeyboardInterrupt} exception, and other @value{GDBN} exceptions > -- calls to @code{error} in the C code -- are translated to Python > @code{RuntimeError}s. That's a step in the right direction, but only one step; more is needed to make this palatable to the manual readers who are not GDB hackers. We cannot mention the `error' function, for example, since we don't want the reader to read GDB sources to understand what that means. Here's something that should explain what I have in mind (details might be factually incorrect): When executing the @code{python} command, Python exceptions uncaught within the Python code are translated to calls to @value{GDBN} error-reporting mechanism, which terminates the currently executing command and prints 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: @smallexample ... @end smallexample @value{GDBN} errors that happen in GDB commands invoked by Python code are converted to Python @code{RuntimeError} exceptions. User interrupts (via @kbd{C-c} or by typing @kbd{q} at a pagination prompt) is translated to a Python @code{KeyboardInterrupt} exception. If you catch these exceptions in your Python code, your exception handler will see @code{RuntimeError} or @code{KeyboardInterrupt} as the exception type, @code{None} as its value, and @value{GDBN} backtrace as the traceback.