[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] around advice & exceptions
|
Ron Bodkin wrote:
It also turns out that you can use some holes in the Java checked exception
checking rules to throw arbitrary checked exceptions from 100% pure Java
source code. Take a look at Bob Lee's blog entry:
http://weblogs.java.net/blog/crazybob/archive/2004/09/dont_try_this_a.html
both Thread.stop(Throwable) and Java5 generic exception blindness both
seem to be convinient workarounds for the problem.
And this one that uses com.misc.Unsafe class to throw arbitrary checked
exceptions: http://www.oreillynet.com/pub/wlg/5559
I don't consider anything that imports sun.whatever to be pure Java ;-)
So if you want to write advice that throws arbitrary checked exceptions, you
can do so even with pure Java code, but you are then relying on the advice
programmer to ensure correct exception types.
I agree with Rafal that there are cases where you want to be able to throw
checked exceptions that are compatible with the specific join point in
question.
I was thinking about other ways of adding this feature into the
language, because I must admit that "... throws MagicException" is not
very straightforward way of doing it.
My other ideas were:
1) extension of JoinPoint contract:
JoinPoint.canThrow(Class<? extends Throwable> c);
JoinPoint.throw(Throwable t) throws ExceptionContractViolationError;
Such pair or methods allows the advice code to make an informed decision
about rethrowing the caught checked exception or handling it otherwise
(logging, or wrapping in a concern-specific exception). Another
advantage is showing clearly where the information about possible
exceptions exists and where the decisions are made. A con is that
throw(Throwable) method would have to be bytecode engineered to throw
checked exceptions in extralinguistic manner.
2) special construct for around advice in parallel to proceed()
proceedByThrowing(Throwable);
Not too good idea probably, because 1) before/after advice can deal with
joinpoint specific checked exceptions in some contexts, and 2) it works
differently than the proceed() contstruct that proceeds "inward" and
then "outward", where proceedByThrowing() proceeds only "outward".
Re: Wes's suggested use of proceed with different context parameters, it
works if the proxy has a type that's compatible with the signature of the
original join point (e.g., at a call on a interface's method, an interface
implementation, at execution of a class's method, a subclass).
If you want to have proxies that have just a common interface or even just
implementing the same method signatures, rather than having the proxy be a
subclass, you would have to use a reflective approach. I don't think Rafal's
code allows this either: even if it used proxyProceed(delegate,
thisJoinPoint);, the reflective call on the method would rely on the same
type. I think you could allow it by looking up a method on the delegated
object with the same signature as the original. This would be another
possible use case for this kind of polymorphic checked exception.
That's all true, but for my particular testcase the delegates would be
clones of the original object type-wise. (Shared read-copy or write-copy
excusively owned by one thread).
Rafal
