Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark@klomp.org>]

Hi Kris,

On Thu, 2007-11-15 at 15:40 -0500, 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...).

Yes I did mean that it would be ideal if the right submodule handled
issues and returned a more specific result or exception, so the command
doesn't have to handle it. The "at the appropriate level" in the above
was meant to indicate that it isn't necessarily at the Command class
level, but through the while chain of commands that are needed for the
command. Bad English there, sorry.

But I don't think it is bad for all exceptions to be passed up to the
CLI level. If we had exception types for "unable to access needed
inferior/core data" that would already be helpful at the Command level.
Then the Command could at least report that it tried but failed for a
specific reason. The current situation that we don't have specific
exception messages for different kinds of failures (some fatal system
issues, some logic programming errors, some invalid data, some unable to
access data, etc) makes it impossible to properly report to the user why
something failed or why a result may only be partly correct.

Cheers,

Mark