public class PersistenceException extends Exception {
}

 

This code will compile and even work, but would you write a custom Exception like this ? Would you add anything to this class, if you were writing it ? I think I would, but let's first see what we can do with this class as it is. 

 

Typical client code which uses it would look like this. 

 

throw new PersistenceException();

 

That's great, but what if I want to supply a message with the custom Exception, or what if I want to supply a cause, or maybe a message and a cause. The simple Exception class we showed above will not work for any of these complex scenarios. 

 

Someone remarked "maybe the developer who wrote this was lazy". Well IMO there is nothing wrong with laziness. A good programmer is supposed to be lazy. Lazy programmers hate repeating the same thing over and over again, so they will often write a generic, reusable classes (or functions, or modules), which they can reuse from different parts of their code. Lazy programmers also create utilities to automate their tasks. Laziness is not necessarily bad - as long as it does not degenerate to sloppiness. Much can be said about sloppy programming, and the example I have shown above is possible like a small ripple compared to the sloppiness that is possible. But I digress - laziness or sloppiness is not the purpose of this post.

 

Coming back to custom Exceptions, lets turn to Eclipse and see what it generates when we create a new subclass of java.lang.Exception, using it new class wizard. Notice the red arrow, because without checking the "constructors from superclass" option, you will get the exact code shown above.

 

 

 

public class PersistenceException extends Exception {

    public PersistenceException() {
        // TODO Auto-generated constructor stub
    }

    public PersistenceException(String arg0) {
        super(arg0);
        // TODO Auto-generated constructor stub
    }

    public PersistenceException(Throwable arg0) {
        super(arg0);
        // TODO Auto-generated constructor stub
    }

    public PersistenceException(String arg0, Throwable arg1) {
        super(arg0, arg1);
        // TODO Auto-generated constructor stub
    }

}

 

I love this, because now I can write far more richer client code. I can add a message to the Exception -

 

String msg = "Cannot connect to data store"

throw new PersistenceException(msg);

 

or a cause -

 

try {
    writeData(d);
} catch (FileNotFoundException fnfe) {
    throw new PersistenceException(fnfe);
}

 

and even a message with a cause - 

 

We can never know how a custom Exception will be used by it's clients, and it's best we do not try to guess (in this case) either. The best way to create a custom Exception is to always override all four methods from java.lang.Exception.