From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25277 invoked by alias); 17 Mar 2011 16:22:01 -0000 Received: (qmail 25264 invoked by uid 22791); 17 Mar 2011 16:21:59 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Mar 2011 16:21:55 +0000 Received: (qmail 6070 invoked from network); 17 Mar 2011 16:21:53 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2011 16:21:53 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [unavailable regs/locals, 01/11] registers status upwards Date: Thu, 17 Mar 2011 16:48:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.1; x86_64; ; ) Cc: Jan Kratochvil References: <201102221327.51130.pedro@codesourcery.com> <201103160012.50971.pedro@codesourcery.com> <20110317150627.GA15201@host1.jankratochvil.net> In-Reply-To: <20110317150627.GA15201@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103171621.48928.pedro@codesourcery.com> 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: 2011-03/txt/msg00899.txt.bz2 On Thursday 17 March 2011 15:06:28, Jan Kratochvil wrote: > Yes, for callers who want to deal with it there should be some way to report > it without the GDB exceptions magic. The key point is that the interface/prototype of the current functions has been designed from the start to return a status indication instead of throwing. The non-valid status of registers is _not_ new. A nicer throwing variant interface would return the register's value, instead of void. That interface/prototype would make it obvious to the reader that since there's no way to return an error indication by return value, then it must throw. > I wanted to express general disagreement with this style expecting preciseness > and no mistakes by the developers, which is not considered to be a "safe > enterprise development style". Another key point, is that not putting a TRY_CATCH were it would matter is fragile as well. The whole operation is cancelled. It makes the whole user experience _worse_. Seing 0s is worse than at places, but it's much better than not seeing _anything_ at all. E.g, the MI command I showed upthread. How about proceeding as is, and I'll revisit later if necessary? This is just _one_ detail in the whole story afterall. -- Pedro Alves