Pluggable Error Handling Strategy

Question

Hi,

I have service object (Service A), that has some specific repetitive asynchronous task . This service object also has a supervising object (Service B). I want to handle most of the errors concerning the specific task in Service A and only inform Service B if it needs to take any additional measures (e.g. when Service A does not know how to handle the error).

Since Service A depends on external resources (e.g. network availabilty) there are many different exceptions, that can be thrown and I do not know all of them right now.

Because of that I would also like to have a pluggable eror-handling strategy inside Service A so that it can handle different exceptions differently. I would like to plug in those stratgies using my IoC container.

Example A: Service A is suppsoed to download something every 30 sec. (polling), but the URL is malformed so a MalformedURLException is thrown. A looks up the error handling strategy for MalformedURLExcpetion and in this case the strategy will mean canceling the download and informing Service B (the supervisor) via a callback.

Example B: Service A is supposed to download something, but the hostname cannot be resolved. Again an Exception is thrown (sorry don't know exacpt type now) and the corresponding strategy will be looked up: in this case the download should be stalled and retried at another time until a certain threshold is hit.

My problem now: How should I implement this dynamic lookup of error handling strategies and the strategies themselves? Is there a pattern for that?

(Sorry for this lengthy post)

Answer 1

Try Observer pattern. In general, your ServiceA should have methods like addFirstTypeExceptionsListener (ServiceListener l) addSecondTypeExceptionsListener (ServiceListener l)

or addExceptionListener (ServiceListener l, ExceptionTypeEnum type).

Your ServiceB then should implement ServiceListener interface which will probably have method like handleException (Exception e);

---

If we abstract away from your question then it's a bad practice to use exceptions for flow control.

Answer 2

Well, the easiest and straight forward solution would be tu use plain java try catchs, not that flexible, but often useful enough as error handling strategies does not change that often. Those exceptions you can not catch are declared on the method to may be thrown, and may be handled by your Object B.

If you wanna be more flexible. Create an interface for your service A with all the possible exceptions declared. Implement that interface with logic but without any error handling. Then you could create ErrorStrategy objects that implement the interface as well and delegate incoming calls to another implementation of that interface, BUT and this is the interesting part append some error handling strategy for one or more particular exceptions. Here is an example to make it more understandable.

public interface A {
    void someMethod() throws IOException, MalformedURLException;
}

class AImpl implements A {
    @Override
    public void someMethod() throws IOException, MalformedURLException {
        // here goes your business logic
    }
}

class ErrorHandlerOne implements A {

    @Override
    public void someMethod() throws IOException {
        try {
            delegate.someMethod();
        } catch (MalformedURLException e) {
            // handle the exception
        }
    }
}

If you wanna be even more flexible, I would recommend to use AOP mechanisms instead of the simple delegation chain, that way you can easily plug-in and exchange your error handling strategies. If you use Spring and your Service A is a Spring-Bean you could easily use Springs build in AOP support. In that case the after throwing advice is what you looking for.

After throwing advice: Advice to be executed if a method exits by throwing an exception.

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.AfterThrowing;

@Aspect
public class AfterThrowingExample {

  @AfterThrowing(
     pointcut="com.xyz.myapp.A.someOperation()"
     throwing="ex")
  public void doRecoveryActions(IOException ex) {
    // ...
  }
}

Answer 3

Keep it simple and use plain exceptions.

They are already meant to implement different error handling strategies: you can catch different exception and act accordingly. You can implement your own error handling scheme as long as exceptions remain, well, exceptional. Otherwise if it's really control flow, you should think about it differently.

Here is one in pseudo-code:

• CannotDownloadException. When the download is realy not possible. Fatal error.
• RetryDownlaodException. When the download is momentary not possible. Can implement retry logic.

The names are not so good, but it illustrates the principle.

class ServiceB {

  private serviceA serviceA;

  public download( URL url ) throws CannotDownloadException
  {
       try
       {
               serviceA.download( url );
       }
       catch( RetryDownloadException ex )
       {
             // you could have here something more elaborated that would
             // perform a retry strategy based on a configuration (e.g. the number of retry, 
             // or the interval between retry)
             try
             {
                  sleep( 10 sec );
                  serviceA.download( url );
             }
             catch( RetryDownloadException ex )
             {
                  throw new CannotDownloadException();
             }
       }

  }
}

class ServiceA {

  public download( URL url ) throws DownloadException
  {
       try
       {
               if( ! url.isValid() )
                   throws new CannotDownloadException();

               serviceA.download( url );
       }
       catch( ConnectionException ex )
       {
             throw new RetryDownloadException();
       }
   }
}