Re: fhpd vs RuntimeExceptions

[Kris Van Hees <kris.van.hees@oracle.com>]

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