From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31408 invoked by alias); 16 Nov 2007 10:12:40 -0000 Received: (qmail 31399 invoked by uid 22791); 16 Nov 2007 10:12:39 -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:12:35 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1IsyBb-0001bN-H8; Fri, 16 Nov 2007 11:12:33 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Sami Wagiaalla Cc: Phil Muldoon , frysk@sourceware.org In-Reply-To: <473C8E08.3070305@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <473C8E08.3070305@redhat.com> Content-Type: text/plain Date: Fri, 16 Nov 2007 10:12:00 -0000 Message-Id: <1195207951.3001.6.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/msg00148.txt.bz2 Hi Sami, On Thu, 2007-11-15 at 13:20 -0500, Sami Wagiaalla 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. > > > 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. Yes I agree, having explicit exception types would give the caller the opportunity to decide how to handle the exception. At the lowest level it would be good to communicate the distinction between "cannot access data" (peek or poke of inferior memory or register, which probably indicates a real error or "out of bounds" access) and "invalid data" (or data structure in inferior/core is inconsistent, so I am unable to reconstruct a specific table or type). Cheers, Mark