From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31173 invoked by alias); 16 Nov 2007 11:21:29 -0000 Received: (qmail 31004 invoked by uid 22791); 16 Nov 2007 11:21:26 -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 11:21:21 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IszG8-00025n-Ut; Fri, 16 Nov 2007 12:21:18 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Phil Muldoon Cc: frysk@sourceware.org In-Reply-To: <473C8D99.4060107@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <473C8D99.4060107@redhat.com> Content-Type: text/plain Date: Fri, 16 Nov 2007 11:21:00 -0000 Message-Id: <1195212076.3001.45.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/msg00152.txt.bz2 Hi Phil, On Thu, 2007-11-15 at 18:19 +0000, Phil Muldoon wrote: > Mark Wielaard wrote: > > On Thu, 2007-11-15 at 17:01 +0000, Phil Muldoon wrote: > > > >> As talked about on IRC over the corefile > >> message design, exceptions can and are used to carry warnings, messages > >> and so on. How do you differentiate between a warning and an error in > >> this case? > > > > By using different exception types, so a higher level can distinquish > > between a "recoverable" warning and a "unrecoverable" error. > Like I mentioned in reply to Sami's email yesterday, having a napi throw > several different unchecked exception types places a huge and unfair > burden on the user to know the code beyond the api. The places "must be > an expert on Frysk to call Frysk apis" charge at our feet. Yes, if we stick with unchecked exceptions then they cannot really be part of the api (or they need to be very clearly documented). Unless we define a very small specific set (that doesn't overlap with the core RuntimeExceptions) that are used consistently in all the code. > > 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. > > What would be helpful here? It's a message, not an error? Basically it > just means cannot read the address here as we don't know how to read it. > I can format the message however I want, but it is still not an error > message. However it sure looks like one now ;) It is neither a user message, nor an error. I do see your point. You have only partial information and would let the user know somehow that you will be unable to perform all requests. I like Kris suggestion to have a more specific result or exception here that says "Missing Map Data", then a higher level can decide to act on that and suggest how the user can help, or suggest what normal causes for such missing/corrupt information is. Cheers, Mark