The "around" pattern

Chanwit Kaewkasi chanwit at gmail.com
Fri Jul 3 17:09:55 PDT 2009


> On Sat, Jul 4, 2009 at 12:08 AM, Charles Oliver
> Nutter<headius at headius.com> wrote:
>> John, I had a couple thoughts on the "around" adapter we were talking
>> about for e.g. synchronization.
>>
>> * Around would specify a before, body, and after
>> * Guaranteed execution of the "after" would be specified by a flag?
>> You may not want to run it if there's an exception.
>> * Synchronization would be a special case of the "around" but I think
>> there may need to be a special method to create it, something like:
>>
>> synchronizeAround(target, selector)
>>
>> where target is the body of the synchronized section and selector
>> receives target's arguments and returns an object to sync against.
>>
>> The general case of around would be simpler to use for "finally" than
>> the catchException adapter, since you could just have this:
>>
>> around(target, noop, finallyBlock, true)
>>
>> Where the args are "body, before, after, finallyOrNot?"
>>
>> I've been trying to figure out a clean way to do a finally with
>> current adapters, but it's a little cumbersome. Suggestions?

Hi,

After re-reading, I probably be able to share a bit from my AOP side.
There are 3 kinds of after advice: "after returning" - for the normal
flow, "after throwing exception" - in case of an exception is thrown,
and "finally after" which is always performed.

Not sure if you'd like to support all of them.

Cheers,

Chanwit

>> - Charlie
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
>
>
> --
> Chanwit Kaewkasi
> PhD Candidate,
> Centre for Novel Computing
> School of Computer Science
> The University of Manchester
> Oxford Road
> Manchester
> M13 9PL, UK
>



-- 
Chanwit Kaewkasi
PhD Candidate,
Centre for Novel Computing
School of Computer Science
The University of Manchester
Oxford Road
Manchester
M13 9PL, UK



More information about the mlvm-dev mailing list