How can I make an incorrect pointcut expression throw an exception?

Robert Mugattarov :

I have the following pointcut expression:

@Pointcut("execution(* apply(..))")

Now if the advised methods are renamed to applyTo then the pointcut is no longer correct and the advice will never fire. The failure of the advice will go unnoticed because an incorrect pointcut would not be raising any exceptions at application startup or during runtime.

I have looked through the Spring AOP docs but could not find a way to make pointcuts fail with an exception. Is there a way?

kriegaex :

Antonio is 100% right, there is no error here. The pointcut just says: "If you happen to find joinpoints matching this description, apply my aspect advice there".

• Joinpoint matching is done during runtime in Spring AOP. So it is an inherently dynamic thing.
• The same is true for AspectJ with load-time weaving (LTW). There is always a chance that the classloader loads new classes which are then dynamically matched against pointcuts and aspect code woven into them. So you can never know that you are "done" with aspect weaving. When would you issue a warning or an error?
• If you use AspectJ with compile-time weaving (CTW), the AspectJ compiler will issue a warning Xlint:adviceDidNotMatch if during compilation an advice's pointcut could not match any joinpoint at all. But think about it, it could never be more than an information or a warning because if you compile an aspect module which you later want to apply to a multitude of applications or other modules within one application, no matter if you are using CTW or LTW, matching joinpoints are only found later when weaving those modules.

So this is no error, otherwise you could never use aspect libraries or LTW in general. The whole idea of aspects is that they are independent of application code.

Besides, if you rename 99% of your apply methods to applyTo but for some reason - intent or oversight - keep a single apply method, the pointcut would still match, so your hypothetical error would not be yielded either. Your error is not syntactic but semantic, how can an aspect weaver know that? As Antonio said, refactor with care. In this special case you could change the pointcut to apply*, then it would match both apply and applyTo but also applyMagic which maybe you do not want.

Stultuske's idea to match annotations instead of method names is what I call the "poor man's approach to AOP" because it still scatters AOP-related information throughout your code base and thus does not deliver on the AOP's promise to not only get rid of code tangling but also of scattering. The scattering now only applies to annotations instead of inline method code. I personally like AOP best if you do not see it in the application code at all, except for cases where you want certain features applied declaratively and for some reason document that in the source code with annotations such as @Transactional. But that is a matter of taste, I would probably still try to get the declarations into the aspect pointcuts instead of the application. Only if the overall matching pattern is too complex to handle in pointcuts I might use annotations instead. The widespread practice of linking annotations and aspects and even making that some kind of "AOP design pattern" is misguided and thus over-used, IMO. The pattern has its good uses, but far fewer than I see.