Re: fhpd vs RuntimeExceptions

[Kris Van Hees <kris dot van dot hees at oracle dot com>]

On Thu, Nov 15, 2007 at 01:20:56PM -0500, Sami Wagiaalla wrote:
> Mark Wielaard wrote:
>> 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.

Well, yes and no.  From the perspective of the thrower there can definitely be
a determination on whether a problem is persistent or temporary, i.e. whether
the operation can be retried.  Likewise, the thrower may be able to indicate in
the exception whether there may be an alternative resolution (but leaving the
decision on whether that is used to the caller).  That's a less common way to
use exceptions, but it definitely has its uses.

The caller can have its own decision logic on how to handle exceptions.  E.g.
it is very well possible that the thrower considers a problem persistent, while
the caller knows some alternatives to try.  Looking for a file in different
locations is a typical example of that.  The thrower will typically indicate
that the given file (specified with an absolute path) cannot be accessed, while
the caller may have a couple of directories left to try.

One common problem with exceptions that I keep running into with projects is
overuse of letting exceptions float up until someone handles it.  More often
than not, exceptions end up floating across component boundaries.  In those
cases, it might be more appropriate to catch the exception, and throw a new
one (using the caught one as reason) to indicate the exception status on the
level of the current component.

	Cheers,
	Kris