[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [aspectj-users] Excluding Particular Joinpoints
- From: "Tobias Dunn-Krahn" <tdunn-krahn@xxxxxxxxxxxxxxxx>
- Date: Tue, 6 Dec 2005 10:55:46 -0800
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcX2m+pn7WBo8SADT5eD8nE0uhyz7gD+nC/w
- Thread-topic: [aspectj-users] Excluding Particular Joinpoints
I just wanted to thank everyone for their input on this issue. I did
find a solution that works for us (a combination of several of your
suggestions) and have a much better idea about what's possible.
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Dean Wampler
Sent: Thursday, December 01, 2005 9:23 AM
Subject: Re: [aspectj-users] Excluding Particular Joinpoints
On 11/30/05, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> Just to clarify my original posting, I was showing how to match
> handler join points that are enclosed inside annotated methods (or
> sources). The only way to do that is with code like I posted (you
> it in an if pointcut designator if you like).
> Dean's code is the right way to match join points (such as method
> that exit by an exception from an annotated method.
Yes. I should have added that my version assumes you are willing to
refactor the original code so that the logic that might throw an
expected exception is done in a separate method, allowing you to
annotate it. Personally, I would try to make that design tradeoff, if
Is it a good tradeoff? I believe it is, even though some might argue
that such a refactoring violates obliviousness in some way, because
you're modifying the original code. The refactoring "signals" to
potential observers (aspects, other objects, tools, and human readers)
the expected behavior of the system, without implying any assumptions
about how that information might be used. It's sort of like
"@SuppressWarnings" in this way.
I've been thinking a lot about "AOD" recently, and what I'm finding is
that explicitly exposing metainformation about behavior, like this,
using annotations or other "protocols", keeps coupling between aspects
and objects loose and promotes sophisticated coordination between them
in ways that can't be supported through a purely oblivious appoach.
I've seen this in my <shameless-plug>Contract4J</shameless-plug>
project. (I'm working on a blog about these ideas...)
An explicit refactoring like this feels better to me than having to
use reflection to avoid modifying an API (assuming you have that
choice...). Both the refactored advised code and the aspect code are
simpler and their intent more explicit. They are both more general
purpose, and it seems to me they are less likely to break in some way
down the road.
Sorry for the long digression ;)
aspectj-users mailing list