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

Re: exception handling patterns, I have done some work on how to effectively 
handle exceptions in AspectJ. It is a topic Adrian Colyer and I will be 
teaching on in our OOPSLA tutorial on Enterprise AOP later this month. You 
can also see slides at http://www.newaspects.com/presentations. And there is 
more complete example code showing use of AJ for exception handling at the 
aTrack bug tracker project at https://atrack.dev.java.net/ The project has 
not yet created a release, but you might find the exception handling code 
interesting.

Re: polymorphic exception handling, a little while ago I posed a question on 
this same topic to the users list, and proposed two solutions 
(http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg00599.html, 
http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg00619.html).

For current use, I wrote a special bytecode compiled method, dynamicThrow, 
that can throw potentially undeclared checked exceptions(*). The author of 
the advice needs to take care to not throw undeclared checked exceptions. I 
have used it in my virtual mock objects testing framework (and Chad Woolley 
used the same technique for his).

In future (when J2SE 1.5 comes and there are generics), you'll be able to 
write code like this (see http://dev.eclipse.org/mhonarc/lists/aspectj-
users/msg00737.html):
static <T extends Throwable> void dynamicThrow(T t) throws T {
    throw t;
}

I would like to see generics extended to aspects to allow advice that can 
call methods like this correctly. This seems like the "right" way to solve 
the problem.

I also like Ramnivas' exception introduction pattern; it is fairly close to 
how Java handles cases like this (e.g., for reflective calls) except that it 
is much less obtrusive. The biggest limitations of the pattern are:
1) you have to know what checked exceptions will be thrown and write code for 
each (which isn't true for cases like a testing framework where you might 
throw ANY)
2) you have to account for superclass throwables (i.e., you need to write
advice for execution(* *(..) throws TransactionException) and for execution(* 
*(..) throws Exception) and for execution(* *(..) throws Throwable).
It would be worth benchmarking the performance overhead is when using declare 
soft to throw and another catch.

I'd definitely like to see a declare soft form that can be used to 
not "soften" RuntimeExceptions; this is a significant problem in using AJ 1.1 
to convert exceptions of many types.

Ron

(*) I haven't had problems using this in practice, though it's conceivable 
some VM might choke when verifying it. 

On Fri, 17 Oct 2003 10:35:24 -0700 (PDT), Ramnivas Laddad wrote
> Inline...
> 
> --- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> > Hi Ram -
> > 
> > Historically the issue with this approach has been losing
> > the traceability of compile-time type checking.  
> 
> For reusable and widely crosscutting aspects (such as transaction
> management example in my email), since the advice is unaware of
> business exceptions, there is no other way but to wrap
> the checked exception in a runtime exception. 
> 
> (Correction to my earlier post: I meant to mark
> TransactionManagementAspect as abstract that contains
> an abstract pointcut -- transactedOperations())
> 
> > What
> > guarantees are there that all exceptions wrapped are
> > unwrapped rather than falling through unhandled?
> 
> In practice, any failure won't hide for a long. Pretty much 
> immediately you will see a stack trace (of course, assuming 
> a test case will cause throwing of a business exception)
> showing corresponding to a thrown runtime exception.
> 
> > 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?)
> 
> Hence the pattern :-) I imagine that with JDK1.5's generics
> support, one would be able to write one aspect and cover
> all business exceptions (although, how a templatetized
> aspects will work is not yet clear).
> 
> > 
> > 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
> > > 
> > 
> > _______________________________________________
> > 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



Ron Bodkin
Chief Technology Officer
New Aspects
m: (415) 509-2895


Back to the top