I am somewhat new to aspectj but I have an observation on how poor error reporting is sometimes. First, I would like to say that in my experience when it comes to failures, knowing the context of the failure is everything. Without context you cannot efficiently troubleshoot a problem and can waste a lot of time and energy. Good exception handling and reporting is an attribute of good frameworks.
Here is my current example: I am working on IDEA with the aspectj weaver plugin that allows to weave aspects incrementally as code is modified (not as good as eclipse but better than ant :-) ) The plugin is directly calling aspectj api classes mainly through BcelWeaver. It uses aspectj 1.6.5. By default the plugin is taking the entire project classpath to find aspects. Unbeknownst to me it took an old version of aspectlib.jar 1.5.3 included as part of testing tool not even used in the production system. Unfortunately it picked the compiled aspects that are included with it. While pre-processing all application compiled classes and aspects it choked on these old aspects and threw a BCException. Here is what I had to work with to troubleshoot the problem: 2009-09-22 17:23:29,695 [ 153761] ERROR - llij.aop.aspectj.AspectJWeaver - malformed org.aspectj.weaver.Declare attribute (length:80)org.aspectj.weaver.BCException: unknown TypePattern kind: 0 org.aspectj.weaver.BCException: malformed org.aspectj.weaver.Declare attribute (length:80)org.aspectj.weaver.BCException: unknown TypePattern kind: 0 at org.aspectj.weaver.AjAttribute.read(AjAttribute.java:131) at org.aspectj.weaver.bcel.Utility.readAjAttributes(Utility.java:98) at org.aspectj.weaver.bcel.BcelObjectType.ensureAspectJAttributesUnpacked(BcelObjectType.java:355) at org.aspectj.weaver.bcel.BcelObjectType.<init>(BcelObjectType.java:146) at org.aspectj.weaver.bcel.BcelWorld.buildBcelDelegate(BcelWorld.java:371) at org.aspectj.weaver.bcel.BcelWorld.resolveDelegate(BcelWorld.java:366) at org.aspectj.weaver.World.resolveToReferenceType(World.java:384) at org.aspectj.weaver.World.resolve(World.java:278) at org.aspectj.weaver.World.resolve(World.java:192) at org.aspectj.weaver.bcel.BcelObjectType.getSuperclass(BcelObjectType.java:210) at org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:821) at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:67) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:520) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:363) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceDescendantsOf(CrosscuttingMembersSet.java:107) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:93) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:59) at org.aspectj.weaver.bcel.BcelWeaver.prepareForWeave(BcelWeaver.java:517) at se.expertsystem.intellij.aop.aspectj.AspectJWeaver.internalWeave(AspectJWeaver.java:198) There is no mention of what class is the culprit. This is as helpful as our old and beloved NPE :-P I had to get the source of the plugin, install it with a version of IDEA devkit, debug my real project and stop the debugger on that exception in order to get the name of that class! Not really user friendly and obviously beyond the standard programmer's time and skills. Therefore I would strongly suggest that you insert at key places catches that wrap the exception with useful contextual info and rethrow it. I would also try to make it so that tools like this plugin may devise compensating mechanism. If aspectj would give a semantically rich exception like InvalidAspectException with the fq name of the class in question and where it came from (what jar...), the plugin could try to work around the problem by proposing to remove the offending aspect. Let me know if you want me to open a ticket for this but I could not do more than this specific case. Jacques _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
