Declare Throws & Re: [aspectj-users] Re: Method-call join point throws r

["rbodkin" <rbodkin@xxxxxxxxxxxxxx>]

I agree: that's a consequence of allowing advice on method calls to throw 
checked exceptions: In general the underlying methods that are advised must 
either handle them or declare them in a throws clause. 

But I don't find this to be a problem; when you add anotherMain to the base 
program, you get a compiler error (it's incompatible) and you have to fix it. 
This is just like if you added a call to a method that throws an unhandled 
checked exception (e.g., if you created a new File, you'd have to add throws 
IOException).

However, on a related item I _would_ really like a declare throws clause that 
would allow one to declare that a set of method executions throw some set of 
exceptions. The cool thing about this is that it would:

1) avoid tangling your _source_ with all kinds of redundant declares 
YET
2) allow clients (especially of libraries) to know what exceptions might be 
thrown

I.e., I think declare throws could be the thing that makes checked exceptions 
an unqualified win instead of a lose for most of us.

Ron

On Mon, 19 Apr 2004 09:39:00 +0100, Matthew Webster wrote
> >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)
> Unfortunately call join points are not tied to single enclosing execution
> join point where throwing a particular checked exception is 
> permitted. Consider the following example: the main() method is OK 
> but when we add "anotherMain()", which has no throws clause, we 
> would get a compilation error. The suggested enhancement could 
> prevent program evolution as changes in the base code might cause 
> existing aspects to break.
> 
> public class HelloWorld {
> 
>       public static void method () {
>       }
> 
>       public static void main(String[] args) throws Exception {
>             method();
>       }
> 
>       public static void anotherMain(String[] args) {
>             method();
>       }
> }
> 
> public aspect Aspect {
> 
>       pointcut method () :
>             call(* method(..)) && withincode(* main(String[]));
> 
>       before () throws IOException : method () {
>             throw new IOException(thisJoinPointStaticPart
> .getSignature().toString());
>       }
> }
> 
> Matthew Webster
> AOSD Project
> Java Technology Centre, MP146
> IBM Hursley Park, Winchester,  SO21 2JN, England
> Telephone: +44 196 2816139 (external) 246139 (internal)
> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> http://w3.hursley.ibm.com/~websterm/
> 
> _______________________________________________
> 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