One of the powers of structured exception handling is that it lets you define your own exception types. That's useful, as your code can communicate a lot of information about what's gone wrong when you use your own custom exceptions.

But sometimes, the custom exception type leaves us asking more questions. Christophe found this Java code from a "big application for a big company".

public class K61Exception  extends Exception {

   /* ... */

   public boolean isReallyAnException() {
      return isReallyAnException;
   }

}

We often describe inheritance as an "is-a" relationship. A K61Exception is a kind of Exception. Except, perhaps, not really. Who knows? Maybe it is, maybe it isn't. You have to check if it really is an exception.

I'm certain the developer who did this thought it was a good idea at the time, probably because there's some module which might throw exceptions which are entirely recoverable. I suspect that isReallyAnException is really meant more to communicate how bad this exception is. I may be giving them too much credit, though.

Regardless, when is an Exception not an Exception? When it's bad code posted here. That's not exceptional at all.

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!