From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9505 invoked by alias); 16 Nov 2007 10:42:04 -0000 Received: (qmail 9495 invoked by uid 22791); 16 Nov 2007 10:42:04 -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:42:01 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Isydz-0001mM-2K; Fri, 16 Nov 2007 11:41:52 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Kris Van Hees Cc: Phil Muldoon , frysk@sourceware.org In-Reply-To: <20071115204038.GC17388@oracle.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <20071115204038.GC17388@oracle.com> Content-Type: text/plain Date: Fri, 16 Nov 2007 10:42:00 -0000 Message-Id: <1195209710.3001.36.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/msg00151.txt.bz2 Hi Kris, On Thu, 2007-11-15 at 15:40 -0500, Kris Van Hees wrote: > 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...). Yes I did mean that it would be ideal if the right submodule handled issues and returned a more specific result or exception, so the command doesn't have to handle it. The "at the appropriate level" in the above was meant to indicate that it isn't necessarily at the Command class level, but through the while chain of commands that are needed for the command. Bad English there, sorry. But I don't think it is bad for all exceptions to be passed up to the CLI level. If we had exception types for "unable to access needed inferior/core data" that would already be helpful at the Command level. Then the Command could at least report that it tried but failed for a specific reason. The current situation that we don't have specific exception messages for different kinds of failures (some fatal system issues, some logic programming errors, some invalid data, some unable to access data, etc) makes it impossible to properly report to the user why something failed or why a result may only be partly correct. Cheers, Mark