Exception Overload!

I try to avoid writing my own exceptions.  I try to use the exceptions that are handed to me first.  If all of the existing exceptions don't make sense for my situation, then I will create my own exception.  I don't know where this trend of every library needing its own exception started.  I don't like it, though.

The program I am currently analyzing created its own exception class called MyException.  This by itself isn't enough to justify blogging about.  What this blog is about is the fact that MyException was one of a set of exception classes.  There was MyJobException, MyNamingException, MyDepotException and so forth.  There was not inheritance tree, either.  They all extended java.lang.Exception.

Normally, this kind of over-exceptionalizing would cause constant exception translation.  This normally would cause a really hard to read stack trace because it would constantly say "Caused by" in it.  In this library every exception was logged and ignored.  This made it really difficult to determine where problems occurred.

I understand if you don't want to tie an implementation to an interface.  Maybe that is why you translate SaxException's to MyException's.  That why, if you stop using a SaxParser and using some other parser, then the interface doesn't have to change.  I get it.  What I don't get is translating IOException.  If I/O is occurring, just let the IOException propagate.  If a file doesn't exist, Java provides a perfectly fine exception for that.  Don't try to translate the exception to MyFileNotFoundException or something like that.  IOException and FileNotFoundException (which extends IOException) already handle that.  Don't reinvent the wheel.