将异常作为方法参数处理

Question

I am looking for a design pattern to handle Exception instances received as method arguments.

To put some context into the question, I am using GWT and have various asynchronous handlers that usually come in a form similar to:

public interface AsyncCallback<T> {

  void onFailure(Throwable caught);

  void onSuccess(T result);

}

So, the onFailure method receives a Throwable instance that I need to handle.

Now, I have a number of exceptions I can receive in this method, for example

• ConstraintViolationException
• TimeoutException
• NoSuchElementException

In my handling code I could of course write the following:

void handleException(final Exception e) {
    if(e instanceof TimeoutException) {
        handleTimeout();
    } else if (e instanceof NoSuchElementException) {
        handleInvalidElement();
    } else {
        stopAndCatchFire();
    }
}

But to my eye, that looks very ugly. The large if..else if chain combined with heavy usage of instanceof seems like something that should be avoided.

I thought that maybe I could use the try...catch construct to handle the Exception using something like the following:

void handleException(final Exception e) {
    try {
        throw e;
    } catch (TimeoutException te) {
        handleTimeout();
    } catch (NoSuchElementException nsee) {
        handleInvalidElement();
    } catch (Exception ex) {
        stopAndCatchFire();
    }
}

But this seems like an abuse somehow. Do you see any downsides to the second approach or another approach I could go with to avoid the first case?

Answer 1

Could you not have a dictionary of exceptionHandlers keyed by the type of exception they handle, then when you get a exception you look in the dictionary for the handler for the exception type. If there is one, then pass the exception to the handler, if there isn't then use the default handler.

So your handler becomes something like this:

void handleException(final Exception e) {
    if (handlers.containsKey(e.getType())
    {
        handlers[e.getType()].handle(e);
    }
    else
    {
         defaultHandler.handle(e);
    }
}

My Java is a bit rusty, so the example is c-sharpy but should be simple enough to translate (though I remembered not to capitalise the first letter of everything :))

This approach should have the advantage that you can add new handlers simply.

It will however suffer if you have the same handler for sub types, as you will have to register each subtype explicitly.

To get around this issue simply make each handler responsible for making the decision about whether it can handle an exception:

public interface ExceptionHandler
{
     bool canHandle(Exception e);
     void handle(Exception e)
}

then just put the handlers in a list an iterate asking each one if it can handle the current exception and when you find one that can, get it to handle it.

Answer 2

But to my eye, that looks very ugly. The large if..else if chain combined with heavy usage of instanceof seems like something that should be avoided.

I don't agree. I think this snippet of code is using both language constructs exactly how they were intended. If the code becomes unmanageable (too many clauses) then you should question the approach to error handling generally, rather than the specifics of this method. At that stage you might want to consider AOP.

The second approach on the other hand is horrible ;)

Answer 3

You can make it more elegant just by handling the if statements inside the exceptions inside the function.

void handleException(Exception e){
    handleOne(e)
    handleTwo(e)
    ...
}

It looks prettier. Of course, every function is always called, but its first line is just an if statement. There are variations - eg make your handle functions guava function objects, put them in a list, and iterate through them until you get the first one that returns "true". Something like:

public class handlerOne implements Function<Exception, Boolean> {

    Boolean apply(Exception input) {        
        return handlerOne();
    }
}

Then your handle function can be something like:

void handleException(Exception e){
    list<Function<Exception, Boolean> list = Object.getHandlers(); //store your handlers somewhere
    for(Function<Exception, Boolean> f : list){
        if(f.apply(e)){
            break
        }
    }
}

That way you insure only one handler which works is called, and you can control the order by changing the order of the list, since the list iterator will return them in order.

Answer 4

Control flow on exceptions should be avoided, and should certainly not be in the onFailure. the onFailure method should be as simple as possible.

Modify whatever code is run asynchronously to handle the exception cases there. The ElementNotFound-exception could be handled by just checking if an element exists prior to doing anything. Timeout-exception could be handled by surrounding the code that can timeout (calling a webservice or something)?) by a try .. catch block. Then extend the result-type T to contain extra information that a timeout occurred or an element is not found - if needed.