From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29447 invoked by alias); 15 Nov 2007 20:41:56 -0000 Received: (qmail 29335 invoked by uid 22791); 15 Nov 2007 20:41:55 -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; Thu, 15 Nov 2007 20:41:47 +0000 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lAFKfRZR028880; Thu, 15 Nov 2007 14:41:27 -0600 Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lAFFuRcV012098; Thu, 15 Nov 2007 13:41:25 -0700 Received: from alchar.org by acsmt359.oracle.com with ESMTP id 5808090341195159240; Thu, 15 Nov 2007 14:40:40 -0600 Date: Thu, 15 Nov 2007 20:41:00 -0000 From: Kris Van Hees To: Mark Wielaard Cc: Phil Muldoon , frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions Message-ID: <20071115204038.GC17388@oracle.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1195148516.3010.27.camel@dijkstra.wildebeest.org> 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/msg00144.txt.bz2 On Thu, Nov 15, 2007 at 06:41:56PM +0100, Mark Wielaard wrote: > Hi Phil, > > << Example exception output deleted - see original message for details. >> > > If this is the way forward, I'll have to gobble exceptions locally in > > CoreCommand, and just deal with them locally. > > Yes, I think that is the way forward. Something terribly failed. And > just passing the "address 6992f8 cannot be found in metadata table." > message to the user is clearly not very helpful if the user just wanted > to run a specific command. Only the command knows if this is something > fatal or not and should catch it at the appropriate level and report > what the exact action was that was attempted and which structure > couldn't be created because of the error. I do not think that an exception like this should ever get handled at the level of the command module. In fact, in a case like this it should never have floated up that high without getting handled. Clearly, being unable to peek at the given address was the result of trying to do some action. The failure to peek at the address either causes that action to fail, or it can be ignored (or otherwise recovered from). Either way, the command module should not be exposed to this level of detail (though the information may need to be retained as a nested exception for more verbose output, etc...). This is similar to the famous NullPointerException. I'd expect we all agree that one of those should never ever float up all the way to the fhpd. Cheers, Kris