[aspectj-users] Method-call join point throws restriction

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

Michael Moser asked (on news:eclipse.technology.ajdt) why advice on method call join points needs its exceptions to conform to the throws clause of the method signature of the called method. It makes sense to me to lift this restriction, and to allow method-call join points to throw any throwable (and follow the normal flow analysis for checked exceptions in Java). Naturally method execution join points need this restriction (so the resulting methods don't throw an undeclared checked exception)

I wonder if the restriction on throwables from method-call join points is a heritage of AspectJ 1.0.x, when method-call was sometimes implemented on the callee-side (and which, therefore, required compatible exceptions in the signature)? And I wonder if this simplifies the life of the aspect weaver (so it doesn't have to replicate the Java compiler's flow analysis for checked exceptions)? If this were changed it would be backwards compatible in the sense that it wouldn't break any existing valid AspectJ programs (though it wouldn't be in the sense that it would allow some programs to be valid that weren't before).

One could argue that the method call should still obeys the post-conditions of the original method even after running advice. But in practice, of course, advice can break all kinds of invariants (and sometimes needs to - Therapon Skotiniotis and David Lorenz give a nice analysis of aspects and invariants in an upcoming research paper).

I'm curious what others think about this? Are there problems in allowing advice on method-calls to throw additional exceptions? Would it be useful? How hard would it be to implement?

Ron