Re: fhpd vs RuntimeExceptions

[Phil Muldoon <pmuldoon@redhat.com>]

Kris Van Hees wrote:
> On Thu, Nov 15, 2007 at 06:41:56PM +0100, Mark Wielaard wrote:
>   
>> Hi Phil,
>>     
>>> << Example exception output deleted - see original message for details. >>
>>> If this is the way forward, I'll have to gobble exceptions locally in 
>>> CoreCommand, and just deal with them locally.
>>>       
>> 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. Only the command knows if this is something
>> fatal or not and should catch it at the appropriate level and report
>> what the exact action was that was attempted and which structure
>> couldn't be created because of the error.
>>     
>
> 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