java.lang.Exception vs. rolling your own exception

Question

At what point would you create your own exception class vs. using java.lang.Exception? (All the time? Only if it will be used outside the package? Only if it must contain ad

Answer 1

I can't imagine specifically throwing a java.lang.Exception if some object/class/method had a problem. It's too generic - if you're not going to create your own Exception class, seems to me like there ought to at least be a more specific Exception-type in the API.

Answer 2

I think you need to ask yourself a slighly different question "What advantage does creating a new exception give me or developers who use my code?" Really the only advantage it gives you or other people is the ability to handle the exception. That seems like an obvious answer but really it's not. You should only be handling exceptions that you can reasonably recover from. If the exception you throw is a truly fatal error why give developers a chance to mis-handle it?

More in depth discussion: Custom exceptions: When should you create them?

Answer 3

I believe that:

catch (Exception e) {
   ...
}

... is an antipattern that should be avoided. You might want one centralized broad catch somewhere in your application, to log an error and prevent the whole application from terminating - but having them scattered around willy-nilly is bad.

Why:

try {
   if(myShape.isHidden()) {
      throw new Exception();
   }
   // More logic
} catch (Exception e) {
   MyApp.notify("Can't munge a hidden shape");
}

So you try this, and due to a coding error, myShape is null. A NullPointerException gets thrown when the runtime tries to derefence myShape. This code reports a hidden shape, when it should be reporting a null pointer.

Either make your own exception, or find a suitably specialized exception in the API. It's not as if extending Exception or RuntimeException is onerous.

Answer 4

When I want to treat my exceptions differently from everybody else's. If I want to catch mine and propagate everyone else's, or if I want to catch someone else's and propagate mine, or if I want to catch both but treat them differently, then I will define a separate class for my exceptions. If I want to treat them all the same, either by propagating both or by catching both (and doing the same thing either way with the caught exceptions), the I will use the standard class.

Answer 5

Start always by using the common exception classes and then when a need appears to handle it specially, change it.

1. When creating a method first time, just let exceptions go through.

2. If there are exceptions that must be handled, those can either be just defined in throws or wrapped to some runtime exception or wrapped own throws exception. I prefer runtime exceptions in many cases. Defining throws definition should be avoided until there is a need for it from API point of view.

3. Later when a need appears to do specific handling for an exception in some caller, come back and create new exception for it.

The point is to avoid doing extra work before knowing what is needed.

Answer 6

I would use the exceptions from the Java API when the exception relates to the API. But if an exceptional situation arises that is unique to my own API then I will create an Exception for it. For example if I have a Range object with two properties min and max and the invariant min <= max then I will create an exception InvalidRangeException.

When I am writing code this helps because I know if the exception originates because I violated one of my own conditions or its something from the Java API.