Re: [Platemail-developer] exception handling

[Neil C. <ne...@th...>]

On Wednesday 16 March 2005 01:15, David Stocks wrote:
> Neil,
>
> What'd you think the best exception handling policy is?  I see you've
> created a PlatemailException class, which I've extended to create a
> RegistryException class, however I'm not sure on the best approach.
>
> As I see it, I (currently) want to have an exception that can be thrown
> when the save/load process fails.  The best behavior here is to have the
> exception pass all the way back to the kernel, which can then perform a
> controlled shutdown.

Yeah, the best thing is probably to throw an exception at the point of failure 
(which includes wrapping any caught IOException or whatever in a 
PlatemailException subclass) and let it bubble up.  We can then catch it at 
the kernel (for now) or catch it somewhere else and try to recover.

> I'm looking to "fail early" here, which I think is the best idea
> generally, however I don't think that a subsystem should do a
> System.exit() call.

Absolutely not.

> Another question is how many such exceptions I should create; one for
> each type of failure?  Should I do something like this:
>
> SaveException extends RegistryException extends PlatemailException
> LoadException extends RegistryException extends PlatemailException
>
> or, should I just have one RegistryException and pass it a string
> specifying the error, which I presume is passed up for
> java.lang.Exception to handle.

It's another of those tradeoff things I guess - we can either have a million 
different classes of exception, or one with a million different strings 
passed in.  Obviously, the middle ground is better.  I'd generally err on the 
side of having different classes, because you can catch them separately.  
Probably the best idea is to have different classes for exceptions that might 
require different handling behaviour, but use the same type for variations on 
a theme that will be handled the same way.

In this case, I'd say that we should handle load exceptions separately from 
store exceptions, because for example we could fail if we can't load a 
settings file, whereas if we can't save it we could still carry on (unless 
the save was part of a shut down).

> I'm leaning toward having an separate exceptions for everything, not
> just things that you might want to differentiate between, though that
> could conceivably be a lot of options.

I think as long as it's part of a hierarchy, we can relatively easily flatten 
it or add levels if the situation requires it in future.  For cases which are 
clearly different though, they should be separate classes.

Neil