From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31245 invoked by alias); 28 Jun 2010 06:26:04 -0000 Received: (qmail 31233 invoked by uid 22791); 28 Jun 2010 06:26:04 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-mx06.nokia.com) (192.100.122.233) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Jun 2010 06:25:57 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5S6PkMQ012641 for ; Mon, 28 Jun 2010 09:25:53 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 09:25:49 +0300 Received: from mgw-da01.ext.nokia.com ([147.243.128.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 09:25:49 +0300 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5S6PkuL001495 for ; Mon, 28 Jun 2010 09:25:47 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb-patches@sourceware.org Subject: Re: [patch] PR python/11407 Date: Mon, 28 Jun 2010 06:26:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.2; i686; ; ) References: <4C23426F.4020502@redhat.com> <4C23D5CB.5040702@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006280826.08385.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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: 2010-06/txt/msg00628.txt.bz2 On Friday 25 June 2010 20:25:10 Tom Tromey wrote: > >>>>> "Phil" == Phil Muldoon writes: > > Phil> I'm not sure what to do in this case. There seems to be no direct > Phil> equivalent of converting an exception to error output on a stream in MI > Phil> (or any cases of TRY ... exception handlers). There are many cases of > Phil> MI raising an error() though, so I thought it appropriate in our case > Phil> to raise a warning() instead. Because of the peculiarities of the MI > Phil> cases I just report a warning generically and move on. This is not > Phil> totally ideal, but it does allow the error/warning preamble followed > Phil> by the actual locals information. > > I'm not convinced a warning is the best thing. > > Why not catch the exception and print the text of it as the variable's > value? Something like > I think this will work ok with existing front ends. I'd guess it would be nice for a front end to get a hint that something unusual happened in case it wants to have some kind of special handling of such cases (like localizing the error message). A separate field error="...", or perhaps value="" as suggested with an additional field iserror="1" would be easier to handle than checking the "value" field for well-known strings, especially if such content could be legal output in some cases, too. [But take this with a grain of salt, I/we haven't used MI for data retrieval for a while now, so maybe there are already enough hints in the output nowadays.] Andre'