Question AOP-Around and Exception handling

[jackkilian]

Hi Spring Gurus,

I have a short design/architecture question.

I plan to map all possible exceptions to one common unchecked exception. In my framework that exceptions get handled afterwards by one central exception handling class.

The code looks like the following.

  
@Pointcut (mapping to any packages...)
... exceptionMappingMethod() {
}

@Around("exceptionMappingMethod()")
protected Object doBasicExceptionhandling(ProceedingJoinPoint pjp) throws Throwable {
	
        //Start centralized exception handling

	Object retVal = null;
	try {
		retVal = pjp.proceed(); 
	} catch (UncheckedError ex) {
				
		switch(ex.getExceptionType()) {
		  case UncheckedError.TYPE_OBJECT_LOCKED_EXCEPTION:
		       //handle specific unchecked exception
		       break;
		  case UncheckedError.TYPE_OBJECT_NOTFOUND_EXCEPTION:
		       //handle specific unchecked exception
		       break;	
		  case UncheckedError.TYPE_ANY_EXCEPTION:
		       //handle specific unchecked exception, but the method call need a return value Booelan(true/false)
		       break;	
                  [...]	
		  default:
		       throw new Exception(ex);	
		}
	}
            return retVal;
}

My design question is now, how do you handle the retVal = pjp.proceed(); call?
Let's assume that it is possible to return an new business object when a DAO exception happen. In the case that the catch block is executed no return value object is available.
What do you think about to put a possible return value into the UncheckedError, and return that value.

The unchecked exception is created like this:
new UncheckedError(UncheckedError.TYPE_ANY_EXCEPTION, <error case object>, SourceException)

The new code segment would look like the following:

@Pointcut (mapping to any packages I need...)
... exceptionMappingMethod() {
}

@Around("exceptionMappingMethod()")
protected Object doBasicExceptionhandling(ProceedingJoinPoint pjp) throws Throwable {
	
        //Start centralized exception handling
	
	Object retVal = null;
	try {
		retVal = pjp.proceed(); 
	} catch (UncheckedError ex) {
				
		switch(ex.getExceptionType()) {
		  case UncheckedError.TYPE_OBJECT_LOCKED_EXCEPTION:
		       //handle specific unchecked exception
                       retVal = ex.getErrorCaseObject();
		       break;
		  case UncheckedError.TYPE_OBJECT_NOTFOUND_EXCEPTION:
		       //handle specific unchecked exception
                       retVal = ex.getErrorCaseObject();
		       break;		
		  case UncheckedError.TYPE_ANY_EXCEPTION:
		       //handle specific unchecked exception
                       retVal = ex.getErrorCaseObject();
		       break;	
                  [...]	
		  default:
		       throw new Exception(ex);	
		}

	}
       return retVal;
}

thx

[Marten Deinum]

The first question that arises is why do you use an around advice... Isn't a after-throws advice better? Also next to that I think you should let your exception bubble up and let the service also do something with the exception, else how are you going to act on it/report it to the user?

[jackkilian]

Hi,
what's the advantage using @AfterThrows instead of @Around from a performance point of view?

When I use following:

  @AfterThrowing(
		    pointcut="mappingMethod()",
		    throwing="ex")  
  protected Object exceptionHandling(UncheckedError ex) throws Throwable {
	
	Object retVal = null;
	switch(ex.getExceptionType()) {
		  case UncheckedError.TYPE_OBJECT_LOCKED_EXCEPTION:
		       //handle specific unchecked exception
		       break;
		  case UncheckedError.TYPE_OBJECT_NOTFOUND_EXCEPTION:
		       //handle specific unchecked exception
		       break;	
		  case UncheckedError.TYPE_ANY_EXCEPTION:
		       //handle specific unchecked exception, but the method call need a return value Booelan(true/false)
		       break;	
                  [...]	
		  default:
		       throw new Exception(ex);	
		}
	
    return retVal;
  }

...I have always the problem that the exceptionHandling() method is informed about the exception, but the exception is not fully catched. Has the same behaviour then not catching it or in other words the exception is thrown to the next method. So, it's an adavantage when I would like to log the exception.
My additional intention is to generate UI dialogs depending on the exception type, to generate common actions depending to the exception type, logging, etc.

regards

[Marten Deinum]

It depends on what you want.

After throws doesn't have a return type it is always a void method. Next to that you are trying to juggle around with the returnValue what happens if your return type is for instance User and you are return a Exception (I would say crash - ClassCastException). And what would you return for a void method?!

You still need the exception to bubble up and let the calling stuff handle it. If you want to do some exception handling stuff for views etc. you probably want to look for the HandlerExceptionResolver (if you use SpringMVC/WebFlow).