From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4557 invoked by alias); 16 Nov 2007 10:28:15 -0000 Received: (qmail 4550 invoked by uid 22791); 16 Nov 2007 10:28:15 -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; Fri, 16 Nov 2007 10:28:13 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IsyQi-0001er-Rn; Fri, 16 Nov 2007 11:28:10 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Andrew Cagney Cc: Phil Muldoon , frysk@sourceware.org In-Reply-To: <473C985F.6010103@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195149852.3010.33.camel@dijkstra.wildebeest.org> <473C985F.6010103@redhat.com> Content-Type: text/plain Date: Fri, 16 Nov 2007 10:28:00 -0000 Message-Id: <1195208888.3001.24.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/msg00150.txt.bz2 Hi Andrew, On Thu, 2007-11-15 at 14:05 -0500, Andrew Cagney wrote: > That unfortunatly isn't sufficient; the old code in CLI.java was > differentiating between and NPE and other exceptions - dumping the stack > when an NPE occured. I'll restore this behavior; so we're at least back > to a usable status quo (and from a HPD user prospective in a better > position - these back-traces plain suck) OK, but I don't understand this heuristic with NullPointerException. You introduced a "nasty()" method (cute name) that gobbles up the Exception except if it is a NullPointerException or has an empty message. But that doesn't seem to cover other catastrophic failures like ClassCastException, ArrayOutOfBoundsException, ArithmeticException, IllegalArgumentException or NumberFormatException, etc. that might or might not have empty messages, but that are real core bugs if they occur and "bubble up" to the CLI. I think your argument that from a user perspective printing fatal exceptions just plain sucks is right. But if there are really fatal exceptions in the core code that then get hidden by the CLI layer we (and we are also our own users) have a hard time fixing those. At least our users will be unable to properly report what went wrong. So the real solution is to just not plain suck, by not having bugs in our core code :) > I'll also add a prototype version of CLI.printError() that we discussed; > and have just EvalCommands use it; we can then refine it as needed. That seems fine. I recommend you also just rip out the whole Message queuing structure and handle that in the same way with a simple printMessage(). Having two different mechanisms for creating user feedback in the CLI is probably confusing. Cheers, Mark