From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27830 invoked by alias); 15 Nov 2007 23:09:16 -0000 Received: (qmail 27823 invoked by uid 22791); 15 Nov 2007 23:09:15 -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 rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 23:09:13 +0000 Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lAFN8tGW007290; Thu, 15 Nov 2007 16:08:55 -0700 Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lAFFuS1Z002164; Thu, 15 Nov 2007 16:08:55 -0700 Received: from alchar.org by acsmt359.oracle.com with ESMTP id 5809027751195168124; Thu, 15 Nov 2007 17:08:44 -0600 Date: Thu, 15 Nov 2007 23:09:00 -0000 From: Kris Van Hees To: Phil Muldoon Cc: Kris Van Hees , Mark Wielaard , frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions Message-ID: <20071115230842.GD17388@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> <473CC40A.6010104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473CC40A.6010104@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/msg00146.txt.bz2 Phil, Thanks for the more verbose explanation of your specific example. Obviously, all special cases will require some exception (no pun intended) to any rule for handling exceptions. Your example might end up being even more complex, because some form of core file corruption could certainly result in a flood of peek failures, making it impractical to report every one of them to the user. That would require more complex logic for dealing with exception handling, to be smarter about how to report that situation. My main point was (not knowing the full details of your specific example) mainly that e.g. a failure to read data at a memory location on behalf of a some task may very well be better reported as e.g. a failure to complete that specific task (probably with reporting of the specific lower level problem as a cause for the task failure). I'd still argue that even in your specific example, the peek failure should probably float up as nested exception in a component specific exception. If you can stand me just making things up as I go for a minute, maybe the getMaps() method could throw a CannotLoadMapException, with something like a CorefilePeekAccessException nested in it to indicate the lower level failure. And the CannotLoadMapException may need to be nested inside a higher level exception as well, to appropriately float up across component boundaries. Beyond this, I actually favour the concept that projects should not use any of the standard Java exceptions and instead should define its own. Whenever I worked on projects that enforced this, I did complain about what a pain it is to define exception classes all over the place - but in the end it did actually turn out to be quite worth the effort. Cheers, Kris On Thu, Nov 15, 2007 at 10:11:22PM +0000, Phil Muldoon wrote: > Kris Van Hees wrote: >> 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...). >> > > Well yes and no. Perhaps I agree with the overall assertions but the > corefile user should always recognizes that a corefile is created from a > dead or dying process (or just a snapshot in some cases). Let's assume the > former for now. The big use-case around core-files is that programmers use > them to debug a process that died some time ago. That process might have > been in any kind of corrupted state. Therefore a read at an address that is > expected to be sane, but is not, should absolutely be reported. But is it > an error in the core file code itself? No. It duly tried to do as asked, > but failed. It cannot diagnose why that failure occurred, just that it > did. It can mean corrupt segments, missing linkmaps table, screwed up > dynamic segment and a whole host of other issues the user (the programmer) > should know about via this feedback. > > I keep bringing this example up as this is my pain now; and perhaps it is a > special case - but normally they are what define the boundaries of the > rules. As it is right now, this is an exception as in "Cannot read where > you want me to read", but it is not an error condition simply as it is just > honestly reporting that it cannot do what one asked. Because a data read at > 0x12345 address is invalid, it should not print a stacktrace to that > effect. This is not an error in the corefile code, but the corefile itself. > That's pretty much the crux of the argument, and separating out messaging > from true errors. > > Anyway, just wanted to give some background to that exception. I realize > now I should have gone into more detail here earlier. > > Regards > > Phil