From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28822 invoked by alias); 14 Nov 2007 15:27:57 -0000 Received: (qmail 28814 invoked by uid 22791); 14 Nov 2007 15:27:56 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,TW_FH,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from agminet01.oracle.com (HELO agminet01.oracle.com) (141.146.126.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 15:27:49 +0000 Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lAEFRTIH026038; Wed, 14 Nov 2007 09:27:29 -0600 Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lAEEBbQo029070; Wed, 14 Nov 2007 08:27:28 -0700 Received: from alchar.org by acsmt359.oracle.com with ESMTP id 5778790141195054047; Wed, 14 Nov 2007 09:27:27 -0600 Date: Wed, 14 Nov 2007 15:27:00 -0000 From: Kris Van Hees To: Andrew Cagney Cc: Mark Wielaard , frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions Message-ID: <20071114152725.GA17388@oracle.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473B09B8.1070104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473B09B8.1070104@redhat.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00127.txt.bz2 On Wed, Nov 14, 2007 at 09:44:08AM -0500, Andrew Cagney wrote: > Mark Wielaard wrote: >> This makes debugging the fhpd itself a little hard. I added a >> possible exception cause to the Message class and while I was at it >> added checks to make sure we don't present the user with an empty or >> null message (which is very uninformative). Currently we always print >> these possible exception causes when they are attached to a Message in >> CLI.flushMessages(). > > We were printing both the error and the stack, that looked terrible (the > number of times an exception occurs for legitimated reasons is surprising); > so they were turned off. Did this turn them back on? While exceptions definitely are expected to occur primarily for legitimate reasons, exceptions should hardly ever be simply printed (along with the stack) because that is pretty much equivalent to not handling it. Some might be very simple cases of needing to write out a message indicating the exception or error, but that is usually more exception than rule. Turning it off is not quite the answer either I think. Leaving it in the state where it spews out excessive information might be better along with bugs filed for the pieces of code that are failing to handle the exceptions appropriately. Otherwise we are simply hiding problems, and making debugging fhpd a lot more difficult as Mark points out. I've found it quite convenient in various projects that deal with this type of issues (Java-based and otherwise) to rather ensure this output goes to stderr so it can be redirected to a file for later examination, as to not interfere with the interactive session. And when specifically debugging some of those issues, not redirecting so they show up inline where they make most sense. Any form of stopping them from being printed has always led to somehow delaying the resolution of the issues that cause the problem in the first place. Cheers, Kris