CODEWITHSUNDEEP
javaexceptioninterface
Viciouss
Viciouss

Reputation: 283

Exception handling and interfaces in Java

I have written an interface and an implementation to it and I can't really decide on the best way to handle the following problem. To make it short, let's say this is the interface:

public interface Node {
    String getNodeName();
    Node getChildByName(String name);
    void addChild(Node node);
    void removeChild(Node node);
}

Now if I wanted to handle exceptions, is it a good idea to make the exception as generic as possible or should I add rather specific ones?

Let's say the method addChild, should it throw a generic NodeException that could potentially be used in any other method so that the implementing class can extend it on demand, or is it okay to go with a NodeAdditionException that only this methods should throw? The advantage of a generic exception would be that I don't need to wrap exceptions if I use one of the methods internally and an exception is throws, I can just let it go up the stack until someone catches it. It will usually go up to the caller of my implementation and he needs to deal with it then. The caller can catch the generic exception to handle all the exceptions with just one routine or catch any of the child classes. This is at the same time a huge disadvantage, as the caller potentially could catch many different child exceptions that don't even need to be used in the current implementation. That is kind of a deal breaker. A way to solve this is to create a set of fixed exceptions for the implementation to be used which also isn't what I would want to do.

The other way would be the specific exception but this also comes at a price. You would have a fixed set of exception that can be thrown and that's it, an advantage, but if you use any method internally you need to catch the exception, wrap it up in a new one and throw it again. If I got it right, this is quite resource heavy and it's a lot of boiler plate code to write, too. In the end I would take this as the cleaner method to handle exception.

Is there any other way to handle exceptions but this that I just can't think off right now, have I overlooked an important detail on these two or do I need to chose the lesser of these two evils? Any help appreciated.

Upvotes: 3

Views: 2702

Answers (3)

Brian S
Brian S

Reputation: 5056

Unless you're giving NodeException special functionality that does not exist in Exception and does exist in NodeAdditionException/NodeRemoveException/etc., you shouldn't be making a super-exception for your Nodes. The client caller will likely use catch(Exception ex){...} if they want a catch-all, anyway. If there isn't any extra functionality there, there is no need for NodeException.

If you do have shared functionality between various NodeException subclasses which doesn't exist in Exception, that's a different story, and you should definitely use a superclass.

Upvotes: -1

matt forsythe
matt forsythe

Reputation: 3922

You could just use unchecked exceptions (i.e. - have your exceptions extend RuntimeException). That way you don't have to declare anything thrown, and implementations can throw anything they like (again, as long as they extend RuntimeException).

Upvotes: 2

Dawood ibn Kareem
Dawood ibn Kareem

Reputation: 79857

Have an inheritance structure in your exceptions; for example, NodeAddException extends NodeException. That way, the catcher of an exception can be as specific or as general as it needs to be.

Upvotes: 3

Related Questions