Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] Fature request: User-specifiable exception in "declare soft"

This is filed in bugzilla for tracking purpose:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=45231
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
   exception thrown.
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>];

For example:
declare soft: RemoteException
            : call(* PaymentService. *(..) throws RemoteException)
            : RemoteRuntimeException;
declare soft: SystemException
            : call(* *.*(..) throws SystemException)
            : TransactionRuntimeException;

When the last part ([: <Runtime Exception>]) is omitted, we could
default to the current behavior, hence maintaining backward
compatibility.

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.

-Ramnivas


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


Back to the top