From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2258 invoked by alias); 14 Nov 2007 15:36:52 -0000 Received: (qmail 2251 invoked by uid 22791); 14 Nov 2007 15:36:51 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,TW_FH X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 15:36:48 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IsKIG-0004Tz-66; Wed, 14 Nov 2007 16:36:45 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Andrew Cagney Cc: frysk@sourceware.org In-Reply-To: <473B09B8.1070104@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473B09B8.1070104@redhat.com> Content-Type: text/plain Date: Wed, 14 Nov 2007 15:36:00 -0000 Message-Id: <1195054603.3027.40.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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/msg00128.txt.bz2 We quickly went over this on the meeting just now. Just a summary to see if I got it all. On Wed, 2007-11-14 at 09:44 -0500, Andrew Cagney wrote: > Mark Wielaard wrote: > > While investigating some bugs I noticed that the fhpd sometimes swallows > > the RuntimeExceptions from the core (and there I thought all was > > fine...). > Just fyi, broadly the message stuff, at least for normal output, is > going away. > > The reason is that the cli alternates between using addMessage and > PrintWriter.print(...) for normal out; so I've been migrating stuff to > just do PrintWriter.print. But this leaves us still needing a way to > consistently report errors. OK, good to know, I had only seen the Message variants in the code that I looked at. The (add)Message stuff had one benefit that it concentrated the generation of Messages so you can easily capture any exception causes, which may patch added. When using "raw" Printwriter calls you would need some way to capture and then report the errors indeed. > > 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? The cases I looked at were things like: http://sourceware.org/bugzilla/show_bug.cgi?id=5286 http://sourceware.org/bugzilla/show_bug.cgi?id=5267 Where there was an internal RuntimeException without a message so you would just see Error: null or Error: "" without any extra info. In those cases when you have an internal RuntimeException you now attach a exception cause to the message (and currently always print it, but that can certainly be made optional - either with a command line option to fhpd when started up or by setting some internal variable - see help set). The main problem seems to be how to categorize RuntimeExceptions. Currently we are mixing internal ones, that should never occur and when they bubble up to the fhpd CLI level should really be reported and "expected" RuntimeExceptions that "mean" something at the fphd level and for which only the message might make sense. Cheers, Mark