[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Question about around() advice and exception handling


David,

> First was the seeming lack of perJoinPoint type
> constructs.


>>AspectJ could also support
>>thisJoinPoint.{get|set}UserState(Object) for per-join-point
>>and thisJoinPointStaticPart..{get|set}UserState(Object) for
>>per-join-point-shadow.  That's a longstanding request --
>>not sure it ever made it into the bug database.


See https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/



"Wes Isberg" <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

10/09/2006 23:22

Please respond to
aspectj-users@xxxxxxxxxxx

To
aspectj-users@xxxxxxxxxxx
cc
Subject
Re: [aspectj-users] Question about around() advice and        exception        handling





> First was the seeming lack of perJoinPoint type
> constructs.

True.  

Just to be clear: the thing you have implemented with a
global hash keyed off the signature I would call
per-join-point-shadow, in that you can get back the state
each time the join point {for that shadow} runs.  A join
point is created each time the program runs the underlying
code.  So by contast and e.g., a simple implementation of
per-join-point state would be using a thread-local that is
initialized and cleaned up by an aspect with the highest
precedence.  AspectJ could also support
thisJoinPoint.{get|set}UserState(Object) for per-join-point
and thisJoinPointStaticPart..{get|set}UserState(Object) for
per-join-point-shadow.  That's a longstanding request --
not sure it ever made it into the bug database.

> Second, I can't seem to figure out how to genericly wrap
> methods in an
> around type construct.
...
> Problem I have in AspectJ is that it seems I must know
> the target methods
> declared checked exceptions.  

Lots of traffic on this issue lately; no neat solution.

Like any Java compiler, AspectJ has to perform checked
exception testing.  Adrian summarized the rule recently:
if advice throws a checked exception, it must be declared
and all join points so-advised must also be declared to
throw a compatible exception.

When I dealt with this, I found I only had to make 6
around advice, since I only really had 6 checked exceptions
in the system.  Not pretty, but not that hard, either,
and you can use a pointcut that picks out all such
join points by matching on the throws clause.

The workarounds are:

- using declare-soft to wrap the checked exception in
a runtime exception (and then unwrapping later).

- using unchecked bytecode to just throw the darn thing
and hope (prove otherwise?) it's caught at some point

hth - wes

On Sat, 9 Sep 2006 15:43:09 -0500
"David Budworth" <dbudworth@xxxxxxxxx> wrote:
> Hello folks,
>
> I was looking in to using AspectJ as a replacement for my
> current JBossAOP
> based aspects but I got stumped on a few things.
>
> First was the seeming lack of perJoinPoint type
> constructs.  Which I
> resolved by making an
> IdentityHashMap<JoinPoint.StaticPart,MyState> type
> cache whenever a new joinpoint was executed.  Works
> basically the same.
>
> Second, I can't seem to figure out how to genericly wrap
> methods in an
> around type construct.
> In JBossAOP it was as simple as:
> @Bind("blah")
> public Object adviceMethod(MethodInvocation mi) throws
> Throwable){
>   Object ret = null;
>   Object fault = null;
>    ...do random stuff this advice wants to do...
>    try{
>      ret = mi.invokeNext();
>    }
>    catch(Throwable th){
>        fault = th;
>    }
>    ...do random stuff this advice wants to do...
>    if (fault) throw fault;
>    return ret;
> }
>
>
>
> Problem I have in AspectJ is that it seems I must know
> the target methods
> declared checked exceptions.  Which isn't really
> possible.
> example:
> @Tx
> public void foo() {
>    ... foo stuff...
> }
> @Tx
> public void bar() throws Exception{
>    ...bar stuff...
> }
>
>
> There seems to be no construct in AspectJ's language (not
> the AJ
> 1.5annotations, I'm using the traditional aspectj style)
> to have a
> catch all /
> rethrow all type thing.
>
> That or I'm just missing it.
>
> I could make an around() aspect with a:
>
> public around() : execution(@Tx * *(..)) {
>    boolean failed = true;
>    try{
>     proceed();
>     failed=false;
>   }
>   finally{
>     if (failed) ...do bad thing (rollback / etc) ...
>     else ...do good thing (commit / etc)...
>   }
> }
>
>
> but that seems odd, plus I'd lose the ability to see how
> something fails.
>
> I don't want to use soften since it seems to mask the
> actual exception
> thrown which would break virtually all of our code (lots
> of JDBC / JMS
> stuff)
>
> It's entirely possible that I'm missing the page with the
> magic syntax of
> something like
> around() throws *? : execution(@Tx * *(..) throws *?)
>
> Aside from my initial hurdles of syntax/convention
> converting from JBossAOP
> to AspectJ, I really like the AspectJ way of doing
> things.
>
> I look forward to taking our JBossAS restart time from
> 3min back down to
> ~2min when this conversion is complete (due to
> limitations in jbaop's aopc
> we must use loadtime weaving which adds 1+min to our
> deploy cycle, which is
> why I'm trying to switch to AspectJ)

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users