Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: why you can't use AspectJ to throw or declare checked exceptions from/in a method -- was Re: [aspectj-users] Some questions/suggestions about AspectJ

Hi Wes,

Actually, what does happen when you do ITD of a method? Something like:

public void MyClass.foo() { ... }

Classes that use this method will have a problem when you do not put the aspect (unwoven), right? Isn't the problem that you are pointing out similar?

Actually, I really would like that, at least in situations similar to the one I have referred, that my project would show me compile time errors if any class, using the methods annotated with @AccessControlled would not handle the checked exception I would like to insert. My point is that it would be a lot easier if I could do that. This way, I could concentrate in one single point in my code, the concerns related to authorization:

public aspect MyAspect {

 declare @method : ... : @AccessControlled;
 // then, I would like to be able to do something like this:
 declare throws AuthorizationException : @AccessControlled !private *.*(..);

}

Notice that I am not trying to make aspect advise throw checked exceptions different than the ones declared in the method:

class MyClass {
  public void foo() { ... }
}

aspect MyAspect {

 before() : call(public void MyClass.foo()) {
   if(true)
     throw new Exception();
 }
}

The alternative for my problem is to write directly in the annotated methods, the throws AuthorizationException. However, we would have this scattered all over the application and very hard to maintain because we can have annotations directly in methods or annotations through ITD.

Best regards,

Paulo

Citando Wes Isberg <wes@xxxxxxxxxxxxxx>:

Hi -

It's easier if you stick to the one-topic rule for emails,
with the subject being the topic.

why it isn't possible
to inject exceptions in methods.

That would mean clients built against the original class
 won't have done the required exception checking.
Generally, it's very important that classes affected by
aspects are binary-compatible with the unwoven/original
classes.  While this is the responsibility of the compiler
and not technically part of binary compatibility as defined
by the JLS, it certainly would be viewed as not
Java-compliant for programs to start throwing (and not
catching) unexpected checked exceptions.

Wes

On Thu, 15 Jun 2006 21:38:49 +0100
Paulo Alexandre Corigo Zenida <paulo.zenida@xxxxxxxx>
wrote:
Hello there,

I have a few questions and suggestions that I would like
to share with the AspectJ community.

First of all, I would like to know why it isn't possible
to inject exceptions in methods. I know it is not
possible to make an advice throw an exception other than
the ones in the contract of a method, which makes sense.
However, why can't we make a method, annotated with a
certain annotation, for example, throw a checked
exception, through ITD? I am working on my master degree
thesis project, about access control, and I am using
annotations to specify the points in the code that
require some kind of permission. This way, I am doing
something like this on methods:

@AccessControlled(requires = "foo")
public void foo() {
  ...
}

In order for client code to be able to deal with the lack
of permissions by the principals, I would like to make it
possible to throw a checked exception (at the moment, I
am just throwing an unchecked exception, which is not
what we want here!). Shouldn't this be possible?
Something like:

declare throws mypackage.MyClass.foo() :
AccessControlException;


Second: I would also like to know why isn't possible to
extend concrete aspects. I have one situation in which I
would like to make the aspect application mandatory (a
concrete aspect) but, at the same time, make it possible
to "refine" the pointcuts definitions in it (an abstract
aspect). More concretely, I have created an aspect which
enforces some policies, which must always be applied.
However, I would like to make it possible to switch from
warning to error messages, as wanted. Example:

public aspect MyAspect {

  public final pointcut all() : !none();

  public final pointcut none();

  public pointcut declareWarningScope() :    all();

  public final pointcut declareErrorScope() :
   !declareWarningScope();

  declare warning :    declareWarningScope() && ... :
"Warning: Blabla";
   declare error :    declareErrorScope() && ... :
"Error: Blabla";

}

This aspect should always be applied but I would like to
make it possible to redefine the declareWarningScope()
pointcut. However, I cannot extend that aspect so I have
a problem! To fix this, I have created a workaround,
together with my thesis advisor (Manuel Menezes de
Sequeira), which I would like to share and, maybe, get
some feedback about it.

The idea is that we put the pointcuts definitions (the
declareWarningScope and declareErrorScope pointcuts) in a
class, which the aspect extends (not an interface so that
the declareErrorScope() can be final):

public abstract class MyClass {
   public pointcut declareWarningScope() :
   mypackage.AnAspect.all();

  public final pointcut declareErrorScope() :
   !declareWarningScope();

}

public aspect MyAspect extends MyClass {

  declare warning :    declareWarningScope() && ... :
"Warning: Blabla";
   declare error :    declareErrorScope() && ... :
"Error: Blabla";

}

Then, when we make the project available for others, we
create two JAR files: one with everything, except the
class MyClass, jar-base.jar, and another one with just
the class MyClass, jar-ext.jar.

When we want to refine the pointcuts definition, we don't
use the second JAR, which will cause a compile time
error, due to the unexistence of the class MyClass. That
forces the user to create that class in the specified
package, where he may define the pointcut as wanted. If
he does not want a redefinition of those pointcuts, he
simply uses both JAR's. What do you think about this
solution? Is there one better for this problem?


Finally, I am using annotations in packages to declare
the permissions for all members of that same package.
This way, I try to verify if the permission requirements
for a certain method have been declared or not in a
certain class or package. However, when those are
declared in packages, I cannot guarantee that the package
have been actually loaded: only if a class in that
package have been loaded, right? This way, I force a
class to be loaded in a certain package. The convention
was that one aspect in my project, when instantiated, is
passed a list of classes that should be instantiated, so
that the packages and their annotations are loaded and
stored in that aspect. However, if we have a class A in
the package pt.iscte but no class in the package pt, the
package pt will not be recognized. So, my question is:
would it be possible to use AspectJ to declare classes on
packages? If that would be possible, I would not have to
create a class myself but I could use AspectJ to create
it, and then pass it to that Aspect that loads the
classes.

I hope I have made myself clear and sorry for the mail
size...

Thanks for your attention and interest.

Cheers,

Paulo Zenida


----------------------------------------------------------------
Mensagem enviada usando o IMP (Internet Messaging
Program).


_______________________________________________
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




----------------------------------------------------------------
Mensagem enviada usando o IMP (Internet Messaging Program).




Back to the top