Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Re: Exception handling framework 
Hi Ram -

Historically the issue with this approach has been losing
the traceability of compile-time type checking.  What
guarantees are there that all exceptions wrapped are
unwrapped rather than falling through unhandled?
Conversely, what guarantees are there that there isn't
some other handler picking up all RuntimeException
and mishandling the wrapped BusinessException?
(read: opportunity for declare warning?)

Wes

Ramnivas Laddad wrote:
The exception declaration rule in AspectJ is similar to one for overridden methods if you consider advice as “extra code” in overriding methods. Just as you cannot declare an overriding method to throw any checked exception not already declared by the overridden method, an advice cannot throw any addition exception not already declared by the advised methods (join points, to be precise).
One way to deal with concern-specific checked exception is to use the “exception introduction pattern” presented in my book – “AspectJ in Action”. I have found this pattern to be quite effective in practice. Here is a quick summary of the “exception introduction pattern” by way of an example (You can download source containing working examples from http://www.manning.com/laddad):
The pattern has two parts. In the first part, you simply throw a runtime exception that wraps the checked exception.
public aspect TransactionManagementAspect { Object around() : transactedOperations() { 
        Object retValue = null;
        try {
            beginTransaction();
            retValue = proceed();
            endTransaction();
        } catch (Exception ex) {
            rollbackTransaction();
           // ex could be, for example, BusinessException
           // <Part1>
throw new TransactionRuntimeException(ex); // </Part1> 
        }
        return retValue;
    }
}
The second part of the pattern reinstates the wrapped checked exception, for the methods that were expecting a BusinessException:
public aspect ReinstateBusinessException { declare precedence: ReinstateBusinessException, TransactionManagementAspect; after() throwing(TransactionRuntimeException ex) throws BusinessException : call(* *.*(..) throws BusinessException) { Throwable cause = ex.getCause(); if (cause instanceof BusinessException) { throw (BusinessException)cause; } throw ex; 
    }
}
Could this pattern have a more direct support in the language itself? Perhaps. Meanwhile, this pattern is serving me quite well. 

-Ramnivas

--- mmonteiro@xxxxxxxxxxxxxxxxx wrote:


I do have one remaining problem: every method in the application


that


could throw an exception should have a "throws ...Exception" in its
declaration, or there should be a try-catch block. The catch should


than


be left empty, as the handling is done by the aspect. I do not see


any


sollution to this problem.


The idea of a exception handling framework looks a good one to me.
The issue of throws clauses and checked exceptions versus AOP has also been troubling me for some time. 
There is some merit in the motivation behind checked exceptions - to
ensure program robustness and reliability in the presence of unpredictable occurrences from the environment and other software components. The problem is that Java's mechanism of tackling this enforces code tangling, exactly what AOP is meant to avoid. 
I think there is a certain tension between checked exceptions and
AOP. Aspects have the potential to modularise the issuing / handling of exceptions just like any other crosscutting concern. It's just that the "throws Exception" rule keeps getting in the way. I find it a bit funny that AOP's most widely used language includes a mechanism that enforces a crosscutting concern into its code. 
IMHO the AspectJ team should one of these days tackle this problem.
The ajc compiler could stop generating error messages due to missing try-catch blocks. ajc could even provide a switch to re-activate the enforced try-catch (perhaps for mission-critical software), just like javac does with the assert statement. After all, AspectJ already enables several things that are forbidden by straight Java - privileged aspects are one good 
example.
Perhaps AspectJ could provide something along these lines in order to
avoid all those try-catch blocks. 
--
Miguel J. T. Pessoa Monteiro
Ph.D. student Minho University, Portugal
eMail: mmonteiro@xxxxxxxxxxxx
URL: http://gec.di.uminho.pt/mpm/ 
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users




__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top