From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8382 invoked by alias); 26 Nov 2007 10:18:56 -0000 Received: (qmail 8374 invoked by uid 22791); 26 Nov 2007 10:18:55 -0000 X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,TW_FH,WLS_URI_OPT_0 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; Mon, 26 Nov 2007 10:18:48 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Iwb37-0001E1-0d; Mon, 26 Nov 2007 11:18:45 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Andrew Cagney Cc: Phil Muldoon , frysk@sourceware.org In-Reply-To: <473DA9B0.10901@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> <1195208888.3001.24.camel@dijkstra.wildebeest.org> <473DA9B0.10901@redhat.com> Content-Type: text/plain Date: Mon, 26 Nov 2007 10:18:00 -0000 Message-Id: <1196072321.3088.11.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/msg00178.txt.bz2 Hi Andrew, On Fri, 2007-11-16 at 09:31 -0500, Andrew Cagney wrote: > True, it gets rid of the immediate problem. More importantly it lets us > walk away from this bike shed and focus on more critical - a corrupt > variable or wrong back-trace is far more serious than the exact text of > an error message. Just like how the dog hears in the farside cartoon > <>, we've ensured that the user at least sees > "Error: ". As our user base expands we can refine this. The immediate problem is not nice error messages (which would be somewhat of a bikeshed that I wouldn't even try to get incolved with seeing I am not even a native speaker). The problem is how we and our users can help each other pinpointing bugs in our code. For example I had to debug a monitor lock issue last Friday. The current setup doesn't show me any stacktraces to help me so it is hard to see where this came from. Hiding information from the current users (us!) is not the right default imho. If unexpected exceptions happen the default should be to show all information to help our users and developers to get at the root cause. > > 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. > > > Of course; however the cli code base is still in rehab from me > refactoring N ways of implementing a command down to one. > Can you create a bug? Here you go: http://sourceware.org/bugzilla/show_bug.cgi?id=5402 Cheers, Mark