[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] detecting missing graphics.dispose()
|
Great to hear. However, there isn't a way to do this at compile time. You
can't match join points that don't embed another join point statically, and
you almost surely want a dynamic condition like cflow to determine the point
at which the dispose is needed. You might consider including this aspect in
tests but not in production as a first step: in that case don't log errors
throw exceptions and cause the tests to fail.
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Mike Schneider
Sent: Thursday, July 26, 2007 1:59 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] detecting missing graphics.dispose()
Cool, thanks. I've been playing with this and it seems to work pretty well.
Is there any way to do this check at compile time instead of run time?
My organization is still a bit skittish about aspects in general so
it's easier to sell compile time checks since it needn't affect the
code directly.
On 7/26/07, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> You can do this fairly easily if you have a logical point after which any
> resources should be cleaned up. Often you use cflow to match some event
> (e.g., a button push for user input or an external message), you track
calls
> to create resources in that control flow and you track disposal. If you
> reach the end of a top-level entry with any resources open, you flag that
as
> an error. Here's the rough idea (not compiled so please forgive any
typos):
>
> aspect TrackResources percflow(topLevelEvent()) {
> public pointcut event() : execution(* Listener+.*(..));
> public pointcut topLevelEvent() : event() && !cflowbelow(event());
>
> private Set<Graphics> open = new HashSet<Graphics>();
>
> after() returning (Graphics g) : call(* Graphics.create()) {
> open.add(g);
> }
>
> before(Graphics g) : call(* Graphics.dispose()) && target(g) {
> open.remove(g);
> }
>
> after() returning: topLevelEvent() {
> if (!open.isEmpty()) {
> logger.error("Failure to dispose...");
> for (Graphics g : open) {
> g.dispose();
> }
> }
> }
> }
>
> Of course you might end up deciding you'd rather automatically dispose of
> resources and just remove that log error, and replace it with another
part:
>
> declare error: call(* Graphics.dispose()) && !within(TrackResources):
> "don't dispose of Graphics scattered throughout the code, let the
> TrackResources aspect do it"
>
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Mike Schneider
> Sent: Thursday, July 26, 2007 11:49 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] detecting missing graphics.dispose()
>
> I've been trying to think of a way to catch a particular bad coding
> practice using aspectj. If anyone can think of how to do it it would
> be fantastic.
>
> Description: when using a Graphics object inside a paint method, it's
> common to create a copy of the object to modify. However then it's
> very important to dispose the object to free up the resources, like
> this:
>
> // good practice:
> public void paint(Graphics g) {
> Graphics2D g2 = (Graphics2D) g.create();
> // do stuff
> g2.dispose();
> }
>
> // bad practice:
> public void paint(Graphics g) {
> Graphics2D g2 = (Graphics2D) g.create();
> // do stuff
> // call to dispose missing!!
> }
>
>
> Can anyone see a way to catch this?
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
