| Re: [aspectj-users] If pointcut and side effects |
| I'm confused myself about what exactly that means, but this is what the programming guide says (appendix B, advice semantics): At a particular join point, advice is ordered by precedence. A piece of around advice controls whether advice of lower precedence will run by calling proceed. The call to proceed will run the advice with next precedence, or the computation under the join point if there is no further advice. A piece of before advice can prevent advice of lower precedence from running by throwing an exception. If it returns normally, however, then the advice of the next precedence, or the computation under the join pint if there is no further advice, will run. Running after returning advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then, if that computation returned normally, the body of the advice will run. Running after throwing advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then, if that computation threw an exception of an appropriate type, the body of the advice will run. Running after advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then the body of the advice will run. Given that, it seems to me, execution order is defined in terms of precedence, and that if some after advice has precedence over some before advice, the after advice will actually start "running" before the join point, but immediately implicitly call the advice with the 2nd highest precedence, and so on. At some point the execution comes back to this after advice, which now executes its body. In effect, it is executing after the join point. This model works well in explaining the rules of precedence among advice, and how for example an around advice not calling proceed might sometimes stop an after advice from running, while sometimes it will not, depending on their relative order: void around() : p() {...} after() : p() {...} (after takes precedence and around not calling proceed won't affect its execution) after() : p() {...} void around() : p() {...} (around takes precedence and not calling proceed will result in the after advice not running) If it reflects the actual implementation, I don't know. Jon On Jun 7, 2006, at 12:17 PM, Eric Bodden wrote:
|