|
Re: Exceptions in advices [message #34217 is a reply to message #34115] |
Fri, 16 April 2004 14:00 |
Eclipse User |
|
|
|
Originally posted by: clemas.uk.ibm.com
Michael Moser wrote:
> But e.g. one of the method's header where this error message is
> displayed reads:
> public void processEvent(IEvent event) throws Exception {
> ...
> * event.setHandled(true); <== red error marker to the left of
> this line
> ...
> }
> Why can't I add an advice that throws an excption here???
The rule in this case is that any advice you write has to have a signature
that matches the join point in terms of exceptions.
For the above method you can write:
before(): call(* setHandled(..)) { ... }
And that will work fine. If we introduce exceptions into the mix, I think
you want to write:
before() throws Exception: call(* setHandled(..)) { ... }
and this will work *IF* the setHandled() method is defined to throw an
exception - I imagine it currently is not and thats why you get the error.
Andy.
|
|
|
|
Method-call join point throws restriction (was Re: Exceptions in advices) [message #34284 is a reply to message #34250] |
Fri, 16 April 2004 16:48 |
Eclipse User |
|
|
|
Originally posted by: rjbodkin.hotmail.com
Michael,
One thing you can do is to use the "Exception Introduction Pattern" (see
AspectJ In Action pages 260-269), i.e., throw an unchecked exception at the
method call that wraps the original exception, and then have advice at the
method execution unwrap it and throw the original, e.g.:
before() : call(* setHandled(..)) {
throw new WrappedRuntimeException(new RealException());
}
after() throwing (WrappedRuntimeException e) throws Exception :
execution(* com.mystuf..*(..) throws Exception) {
throw e.getCause();
}
I agree with you that it would make sense to allow method-call join points
to throw any throwable that their containing method allow. There is a
tension between the view point that the method call obeys the
post-conditions of the original method (i.e., the advice still conforms) and
that the advice can change them. In practice, of course, advice can break
all kinds of invariants.
By contrast, I would not allow method-execution to throw anything that the
method itself can't throw. I think this restriction may be a heritage of
AspectJ 1.0.x, when method-call was sometimes implemented on the callee-side
(and which, therefore, required compatible exceptions in the signature).
I am also going to post about this topic on the AspectJ-users mailing list.
Ron
"Michael Moser" <mmo@zurich.ibm.com> wrote in message
news:c5oq7u$d6t$1@eclipse.org...
> Ahah - I think I get the picture!
>
> The setHandled() method itself does indeed NOT define an Exception,
> but the method in which it is called does (since it first contained
> the coded that I am now trying to inject using an advice and that code
> (and hence the surrounding method) had declared "throws Exception".
>
> I find that a bit odd, since that means that re. Exceptions one is
> actually limited by the Exceptions declared by the "called" code and
> not by the location where it gets called, i.e. where the advice gets
> "inserted".
>
> Isn't that a major draw-back? I mean: wouldn't that be exactly one of
> those things that one expects to be different between using call() and
> execution(). That the latter is bound by the declared throws-clauses I
> perfectly understand and accept, but the former I don't really see
> why. I guess that's more of an implementation issue. I mean, if the
> block within which I advice some statement is already allowed to throw
> a specific exception type, why shouldn't the advice be allowed to do
> so, too?
>
> Michael
>
>
> "Andy Clement" <clemas@uk.ibm.com> wrote in message
> news:c5oot6$auh$1@eclipse.org...
> > Michael Moser wrote:
> >
> > > But e.g. one of the method's header where this error message is
> > > displayed reads:
> > > public void processEvent(IEvent event) throws Exception {
> > > ...
> > > * event.setHandled(true); <== red error marker to the
> left of
> > > this line
> > > ...
> > > }
> >
> > > Why can't I add an advice that throws an excption here???
> >
> > The rule in this case is that any advice you write has to have a
> signature
> > that matches the join point in terms of exceptions.
> >
> > For the above method you can write:
> >
> > before(): call(* setHandled(..)) { ... }
> >
> > And that will work fine. If we introduce exceptions into the mix, I
> think
> > you want to write:
> >
> > before() throws Exception: call(* setHandled(..)) { ... }
> >
> > and this will work *IF* the setHandled() method is defined to throw
> an
> > exception - I imagine it currently is not and thats why you get the
> error.
> >
> > Andy.
> >
> >
>
>
|
|
|
Re: Method-call join point throws restriction (was Re: Exceptions in advices) [message #34320 is a reply to message #34284] |
Fri, 16 April 2004 17:29 |
Michael Moser Messages: 914 Registered: July 2009 |
Senior Member |
|
|
"Ron Bodkin" <rjbodkin@hotmail.com> wrote in message
news:c5p2dq$pc6$1@eclipse.org...
> Michael,
>
> One thing you can do is to use the "Exception Introduction Pattern"
(see
> AspectJ In Action pages 260-269), i.e., throw an unchecked exception
at the
> method call that wraps the original exception, and then have advice
at the
> method execution unwrap it and throw the original, e.g.:
>
> before() : call(* setHandled(..)) {
> throw new WrappedRuntimeException(new RealException());
> }
>
> after() throwing (WrappedRuntimeException e) throws Exception :
> execution(* com.mystuf..*(..) throws Exception) {
> throw e.getCause();
> }
Hm - I'll think about that way out. I also ordered the book a few
minutes ago :-)
> I agree with you that it would make sense to allow method-call join
points
> to throw any throwable that their containing method allow. There is
a
> tension between the view point that the method call obeys the
> post-conditions of the original method (i.e., the advice still
conforms) and
> that the advice can change them. In practice, of course, advice can
break
> all kinds of invariants.
>
> By contrast, I would not allow method-execution to throw anything
that the
> method itself can't throw. I think this restriction may be a
heritage of
> AspectJ 1.0.x, when method-call was sometimes implemented on the
callee-side
> (and which, therefore, required compatible exceptions in the
signature).
Here I fully agree! The execution() - at least logically (I don't know
about the reality) - happens INSIDE the method and should definitely
NOT change the throw behaviour of that method. That would allow to
completely change the semantic of a Java language construct (i.e. more
or less making it obsolete) and may break all kind of code that relies
on the correct listing (and handling) of all possible Exceptions
thrown. So that should definitely NOT be allowed.
With the call() construct, however, I would strongly tend to the first
viewpoint you listed above, namely that everything that is allowed at
that point for a "normal" method call should also be allowed for the
advice. I hope that this will be changed in later versions of AspectJ.
Since it's a relaxation if should not do too much harm nor break by
then existing code...
> I am also going to post about this topic on the AspectJ-users
mailing list.
Thanks for the elaboration and cheers,
Michael
|
|
|
Method-call join point throws restriction (was Re: Exceptions in advices) [message #578527 is a reply to message #34250] |
Fri, 16 April 2004 16:48 |
Ron Bodkin Messages: 1 Registered: July 2009 |
Junior Member |
|
|
Michael,
One thing you can do is to use the "Exception Introduction Pattern" (see
AspectJ In Action pages 260-269), i.e., throw an unchecked exception at the
method call that wraps the original exception, and then have advice at the
method execution unwrap it and throw the original, e.g.:
before() : call(* setHandled(..)) {
throw new WrappedRuntimeException(new RealException());
}
after() throwing (WrappedRuntimeException e) throws Exception :
execution(* com.mystuf..*(..) throws Exception) {
throw e.getCause();
}
I agree with you that it would make sense to allow method-call join points
to throw any throwable that their containing method allow. There is a
tension between the view point that the method call obeys the
post-conditions of the original method (i.e., the advice still conforms) and
that the advice can change them. In practice, of course, advice can break
all kinds of invariants.
By contrast, I would not allow method-execution to throw anything that the
method itself can't throw. I think this restriction may be a heritage of
AspectJ 1.0.x, when method-call was sometimes implemented on the callee-side
(and which, therefore, required compatible exceptions in the signature).
I am also going to post about this topic on the AspectJ-users mailing list.
Ron
"Michael Moser" <mmo@zurich.ibm.com> wrote in message
news:c5oq7u$d6t$1@eclipse.org...
> Ahah - I think I get the picture!
>
> The setHandled() method itself does indeed NOT define an Exception,
> but the method in which it is called does (since it first contained
> the coded that I am now trying to inject using an advice and that code
> (and hence the surrounding method) had declared "throws Exception".
>
> I find that a bit odd, since that means that re. Exceptions one is
> actually limited by the Exceptions declared by the "called" code and
> not by the location where it gets called, i.e. where the advice gets
> "inserted".
>
> Isn't that a major draw-back? I mean: wouldn't that be exactly one of
> those things that one expects to be different between using call() and
> execution(). That the latter is bound by the declared throws-clauses I
> perfectly understand and accept, but the former I don't really see
> why. I guess that's more of an implementation issue. I mean, if the
> block within which I advice some statement is already allowed to throw
> a specific exception type, why shouldn't the advice be allowed to do
> so, too?
>
> Michael
>
>
> "Andy Clement" <clemas@uk.ibm.com> wrote in message
> news:c5oot6$auh$1@eclipse.org...
> > Michael Moser wrote:
> >
> > > But e.g. one of the method's header where this error message is
> > > displayed reads:
> > > public void processEvent(IEvent event) throws Exception {
> > > ...
> > > * event.setHandled(true); <== red error marker to the
> left of
> > > this line
> > > ...
> > > }
> >
> > > Why can't I add an advice that throws an excption here???
> >
> > The rule in this case is that any advice you write has to have a
> signature
> > that matches the join point in terms of exceptions.
> >
> > For the above method you can write:
> >
> > before(): call(* setHandled(..)) { ... }
> >
> > And that will work fine. If we introduce exceptions into the mix, I
> think
> > you want to write:
> >
> > before() throws Exception: call(* setHandled(..)) { ... }
> >
> > and this will work *IF* the setHandled() method is defined to throw
> an
> > exception - I imagine it currently is not and thats why you get the
> error.
> >
> > Andy.
> >
> >
>
>
|
|
|
Re: Method-call join point throws restriction (was Re: Exceptions in advices) [message #578553 is a reply to message #34284] |
Fri, 16 April 2004 17:29 |
Michael Moser Messages: 914 Registered: July 2009 |
Senior Member |
|
|
"Ron Bodkin" <rjbodkin@hotmail.com> wrote in message
news:c5p2dq$pc6$1@eclipse.org...
> Michael,
>
> One thing you can do is to use the "Exception Introduction Pattern"
(see
> AspectJ In Action pages 260-269), i.e., throw an unchecked exception
at the
> method call that wraps the original exception, and then have advice
at the
> method execution unwrap it and throw the original, e.g.:
>
> before() : call(* setHandled(..)) {
> throw new WrappedRuntimeException(new RealException());
> }
>
> after() throwing (WrappedRuntimeException e) throws Exception :
> execution(* com.mystuf..*(..) throws Exception) {
> throw e.getCause();
> }
Hm - I'll think about that way out. I also ordered the book a few
minutes ago :-)
> I agree with you that it would make sense to allow method-call join
points
> to throw any throwable that their containing method allow. There is
a
> tension between the view point that the method call obeys the
> post-conditions of the original method (i.e., the advice still
conforms) and
> that the advice can change them. In practice, of course, advice can
break
> all kinds of invariants.
>
> By contrast, I would not allow method-execution to throw anything
that the
> method itself can't throw. I think this restriction may be a
heritage of
> AspectJ 1.0.x, when method-call was sometimes implemented on the
callee-side
> (and which, therefore, required compatible exceptions in the
signature).
Here I fully agree! The execution() - at least logically (I don't know
about the reality) - happens INSIDE the method and should definitely
NOT change the throw behaviour of that method. That would allow to
completely change the semantic of a Java language construct (i.e. more
or less making it obsolete) and may break all kind of code that relies
on the correct listing (and handling) of all possible Exceptions
thrown. So that should definitely NOT be allowed.
With the call() construct, however, I would strongly tend to the first
viewpoint you listed above, namely that everything that is allowed at
that point for a "normal" method call should also be allowed for the
advice. I hope that this will be changed in later versions of AspectJ.
Since it's a relaxation if should not do too much harm nor break by
then existing code...
> I am also going to post about this topic on the AspectJ-users
mailing list.
Thanks for the elaboration and cheers,
Michael
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|