From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26097 invoked by alias); 15 Nov 2007 20:33:53 -0000 Received: (qmail 26088 invoked by uid 22791); 15 Nov 2007 20:33:52 -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:33:40 +0000 Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lAFKXG5k017757; Thu, 15 Nov 2007 14:33:17 -0600 Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lAFFuR1s002040; Thu, 15 Nov 2007 13:33:16 -0700 Received: from alchar.org by acsmt359.oracle.com with ESMTP id 5808066831195158701; Thu, 15 Nov 2007 14:31:41 -0600 Date: Thu, 15 Nov 2007 20:33:00 -0000 From: Kris Van Hees To: Sami Wagiaalla Cc: Mark Wielaard , Phil Muldoon , frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions Message-ID: <20071115203139.GB17388@oracle.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <473C8E08.3070305@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473C8E08.3070305@redhat.com> 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/msg00143.txt.bz2 On Thu, Nov 15, 2007 at 01:20:56PM -0500, Sami Wagiaalla wrote: > Mark Wielaard wrote: >> By using different exception types, so a higher level can distinquish >> between a "recoverable" warning and a "unrecoverable" error. >> > My suggestion would be to create a MetaDataTablePeekFailedException. > Recoverable or unrecoverable is not something that the thrower can decide, > it is the decision of the catcher. For example DwAttributeNotFoundException > can be used to conclude something about a die's type. But in another case > it can mean that your code is looking for a bogus attribute or is looking > at the wrong die. If your code knows why the exception is thrown then by > all means handle it, print a clean stack trace free error/warning message > or nothing at all. Otherwise let it float up. Well, yes and no. From the perspective of the thrower there can definitely be a determination on whether a problem is persistent or temporary, i.e. whether the operation can be retried. Likewise, the thrower may be able to indicate in the exception whether there may be an alternative resolution (but leaving the decision on whether that is used to the caller). That's a less common way to use exceptions, but it definitely has its uses. The caller can have its own decision logic on how to handle exceptions. E.g. it is very well possible that the thrower considers a problem persistent, while the caller knows some alternatives to try. Looking for a file in different locations is a typical example of that. The thrower will typically indicate that the given file (specified with an absolute path) cannot be accessed, while the caller may have a couple of directories left to try. One common problem with exceptions that I keep running into with projects is overuse of letting exceptions float up until someone handles it. More often than not, exceptions end up floating across component boundaries. In those cases, it might be more appropriate to catch the exception, and throw a new one (using the caught one as reason) to indicate the exception status on the level of the current component. Cheers, Kris