Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark at klomp dot org>]

Hi Sami,

On Thu, 2007-11-15 at 13:20 -0500, Sami Wagiaalla 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.
> >   
> My suggestion would be to create a MetaDataTablePeekFailedException. 
> Recoverable or unrecoverable is not something that the thrower can 
> decide, it is the decision of the catcher. For example 
> DwAttributeNotFoundException can be used to conclude something about a 
> die's type. But in another case it can mean that your code is looking 
> for a bogus attribute or is looking at the wrong die. If your code knows 
> why the exception is thrown then by all means handle it, print a clean 
> stack trace free error/warning message or nothing at all. Otherwise let 
> it float up.

Yes I agree, having explicit exception types would give the caller the
opportunity to decide how to handle the exception.

At the lowest level it would be good to communicate the distinction
between "cannot access data" (peek or poke of inferior memory or
register, which probably indicates a real error or "out of bounds"
access) and "invalid data" (or data structure in inferior/core is
inconsistent, so I am unable to reconstruct a specific table or type).

Cheers,

Mark