Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark@klomp.org>]

Hi Phil,

On Thu, 2007-11-15 at 18:19 +0000, Phil Muldoon 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.

> Like I mentioned in reply to Sami's email yesterday, having a napi throw 
> several different unchecked exception types places a huge and unfair 
> burden on the user to know the code beyond the api. The places "must be 
> an expert on Frysk to call Frysk apis" charge at our feet.

Yes, if we stick with unchecked exceptions then they cannot really be
part of the api (or they need to be very clearly documented). Unless we
define a very small specific set (that doesn't overlap with the core
RuntimeExceptions) that are used consistently in all the code.

> > 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. 
> 
> What would be helpful here? It's a message, not an error? Basically it 
> just means cannot read the address here as we don't know how to read it. 
> I can format the  message however I want, but it is still not an error 
> message. However it sure looks like one now ;)

It is neither a user message, nor an error. I do see your point. You
have only partial information and would let the user know somehow that
you will be unable to perform all requests. I like Kris suggestion to
have a more specific result or exception here that says "Missing Map
Data", then a higher level can decide to act on that and suggest how the
user can help, or suggest what normal causes for such missing/corrupt
information is.

Cheers,

Mark