From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23600 invoked by alias); 14 Nov 2007 19:11:02 -0000 Received: (qmail 23586 invoked by uid 22791); 14 Nov 2007 19:11:01 -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 19:10:54 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IsNdP-0005os-PY; Wed, 14 Nov 2007 20:10:50 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Andrew Cagney Cc: frysk@sourceware.org In-Reply-To: <473B3108.4000203@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473B09B8.1070104@redhat.com> <1195054603.3027.40.camel@dijkstra.wildebeest.org> <473B3108.4000203@redhat.com> Content-Type: text/plain Date: Wed, 14 Nov 2007 19:11:00 -0000 Message-Id: <1195067447.3027.63.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/msg00130.txt.bz2 Hi Andrew, On Wed, 2007-11-14 at 12:31 -0500, Andrew Cagney wrote: > from the call; what about: > CLI.printError(String) > and/or/... > CLI.printError(Exception) You mean to replace CLI.addMessage() and do the user feedback directly instead of stacking it in a Message queue and then replaying it? Yes, that makes sense. The current setup does feel a little over-engineered. [There is the issue that you don't have a strong connection to the original Command executed by the user for which this is a response, but we didn't have that in the case of the (add)Message constructs in the first place, so that might not matter at this point. Since from the user point of view the fhpd is single threaded and accepts just one command at a time. It might matter in the future for the gui though since that could be issuing multiple commands at the same time and then you want to have a stronger tie between the issued command and the user response or error message.] > the "logic" deciding what to do with the exception; for instance if > Exception.getMessage() is null/empty then things are bad; dump the > back-trace; but otherwise just print the message (That should cover null > pointer exceptions). I don't think that is the right logic. There are also other RuntimeExceptions like ArrayOutOfBoundsException, ArithmeticException, IllegalArgumentException or NumberFormatException, etc. that don't have empty messages, but that are real core bugs if they occur and "bubble up" to the CLI. Just printing the message isn't enough information for the user to see what really went wrong. If the Exception is truly meant to convey information to the end user in relation to a specific command it should be more explicitly communicated than just by any generic RuntimeException. Cheers, Mark