[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[aspectj-dev] Fature request: User-specifiable exception in "declare soft"
- From: Ramnivas Laddad <ramnivas@xxxxxxxxx>
- Date: Mon, 20 Oct 2003 11:15:53 -0700 (PDT)
- Delivered-to: email@example.com
This is filed in bugzilla for tracking purpose:
Posting here for discussion purpose...
Here is a feature request to enhance the "declare soft" construct in
a fully backward compatible way.
Currently, the "declare soft" construct is used to soften a checked
exception by throwing an org.aspectj.lang.SoftException wrapping in
original exception. I will like the possibility of specifying a
user-specifiable runtime exception. I intend to use such a feature to
specify a concern-specific runtime exception while softening. This
simple change will help in multiple ways. Here are a few:
1. The exception call stack will be clearer. I will now have an
indication of the concern involved by just looking at name of the
2. I can catch specific runtime exception at some higher level to
process it in the most meaningful way. Currently, I need to trap the
generic SoftException and examine the cause (using getCause()) to
check if the checked exception needs to be handled.
As it stands now, I almost never use "declare soft" by
itself. Typically, I wrap the checked exceptions in question in a
concern-specific runtime exception and use a "declare soft" to avoid
exception-related compiler errors. A feature to easily support this
idiom will make the code easy to understand and explain.
Possible syntax: declare soft: <Exception to be softened> : <Pointcut>
[: <Runtime Exception>];
declare soft: RemoteException
: call(* PaymentService. *(..) throws RemoteException)
declare soft: SystemException
: call(* *.*(..) throws SystemException)
When the last part ([: <Runtime Exception>]) is omitted, we could
default to the current behavior, hence maintaining backward
The runtime exception specified must have a way to set the wrapped
exception. This is not a problem for JDK1.4+ as initCause() can always
be used. For the earlier JDKs, we could require that the runtime
exception specified must have the "initCuase(Throwable)" method.
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search