[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Useless error reporting while weaving with aj1.6 aspects compiled in 1.5

Hi Jacques,

please open a bug, I agree the error was poor.


2009/9/23 Jacques Morel <bibou644-aspectj@xxxxxxxxx>:
> 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
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users