Re: Exception handling

Andre Rothe wrote:


This one is definitely not best practice. Avoid it at all costs.


I can't say I know best practice here, but some ideas do occur to me.

Don't forget that Java exception are just regular classes. Any time you
see a construct, for any class, like this:

   if( object instanceof ClassA ) {
     do something ...
   } else if( object instanceof ClassB ) {
     do something else...
   } ... etc., lots more....

You should think polymorphism and overriding.

public interface ExceptionHandler {
   void handler();
}

public abstract class DBFrameworkException
   extends Exception
   implements ExceptionHandler
{
   ExceptionHandler handler;
   void setHandler( ExceptionHandler h) {
     handler = h;
   }
   @Override
   void handler() {
     if( handler != null ) {
       handler.handler();
     }
   }
}

public class DataTypeMismatch extends DBFrameworkException
{
}

Now at least you don't have to check for lots of different classes. If
the class is "ExceptionHandler" you can just execute the handler
method... which might do different things based on the handler that was
installed.

Since the handler can be set, you can make a factory or registry of
handlers, and inject the behavior into the lower layers. No need to
specify at compile time or hard code it, just look for the handler and
install one if it exists. If none exist, maybe an default handler that
just writes to the logger would be appropriate.

This allows you to use fewer classes--you only need one exception class,
really. And you only need as many handlers as you have different
behaviors. No more than you'd have to write in your big ol' if-else
stack you had.