Announcement Announcement Module
Collapse
No announcement yet.
Question AOP-Around and Exception handling Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Question AOP-Around and Exception handling

    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.

    Code:
      
    @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:

    Code:
    @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
    Last edited by jackkilian; Feb 18th, 2008, 10:57 AM.

  • #2
    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?

    Comment


    • #3
      Question AOP-Around and Exception

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

      When I use following:
      Code:
        @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

      Comment


      • #4
        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).

        Comment

        Working...
        X