[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Re: Exception handling framework
|
Inline...
--- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> Hi Ram -
>
> Historically the issue with this approach has been losing
> the traceability of compile-time type checking.
For reusable and widely crosscutting aspects (such as transaction
management example in my email), since the advice is unaware of
business exceptions, there is no other way but to wrap
the checked exception in a runtime exception.
(Correction to my earlier post: I meant to mark
TransactionManagementAspect as abstract that contains
an abstract pointcut -- transactedOperations())
> What
> guarantees are there that all exceptions wrapped are
> unwrapped rather than falling through unhandled?
In practice, any failure won't hide for a long. Pretty much
immediately you will see a stack trace (of course, assuming
a test case will cause throwing of a business exception)
showing corresponding to a thrown runtime exception.
> Conversely, what guarantees are there that there isn't
> some other handler picking up all RuntimeException
> and mishandling the wrapped BusinessException?
> (read: opportunity for declare warning?)
Hence the pattern :-) I imagine that with JDK1.5's generics
support, one would be able to write one aspect and cover
all business exceptions (although, how a templatetized
aspects will work is not yet clear).
>
> Wes
>
> Ramnivas Laddad wrote:
>
> > The exception declaration rule in AspectJ is similar to one
> > for overridden methods if you consider advice as extra code
> > in overriding methods. Just as you cannot declare an
> > overriding method to throw any checked exception not already
> > declared by the overridden method, an advice cannot throw
> > any addition exception not already declared by the advised
> > methods (join points, to be precise).
> >
> > One way to deal with concern-specific checked exception
> > is to use the exception introduction pattern presented
> > in my book AspectJ in Action. I have found this pattern
> > to be quite effective in practice.
> >
> > Here is a quick summary of the exception introduction
> > pattern by way of an example (You can download source
> > containing working examples from http://www.manning.com/laddad):
> >
> > The pattern has two parts. In the first part, you simply
> > throw a runtime exception that wraps the checked exception.
> >
> > public aspect TransactionManagementAspect {
> > Object around() : transactedOperations() {
> > Object retValue = null;
> > try {
> > beginTransaction();
> > retValue = proceed();
> > endTransaction();
> > } catch (Exception ex) {
> > rollbackTransaction();
> > // ex could be, for example, BusinessException
> > // <Part1>
> > throw new TransactionRuntimeException(ex);
> > // </Part1>
> > }
> > return retValue;
> > }
> > }
> >
> > The second part of the pattern reinstates the wrapped
> > checked exception, for the methods that were expecting
> > a BusinessException:
> >
> > public aspect ReinstateBusinessException {
> > declare precedence: ReinstateBusinessException,
> > TransactionManagementAspect;
> >
> > after() throwing(TransactionRuntimeException ex)
> > throws BusinessException
> > : call(* *.*(..) throws BusinessException) {
> > Throwable cause = ex.getCause();
> > if (cause instanceof BusinessException) {
> > throw (BusinessException)cause;
> > }
> > throw ex;
> > }
> > }
> >
> > Could this pattern have a more direct support in the
> > language itself? Perhaps. Meanwhile, this pattern is
> > serving me quite well.
> >
> > -Ramnivas
> >
> > --- mmonteiro@xxxxxxxxxxxxxxxxx wrote:
> >
> >>>I do have one remaining problem: every method in the application
> >>
> >>that
> >>
> >>>could throw an exception should have a "throws ...Exception" in
> its
> >>>declaration, or there should be a try-catch block. The catch
> should
> >>
> >>than
> >>
> >>>be left empty, as the handling is done by the aspect. I do not see
> >>
> >>any
> >>
> >>>sollution to this problem.
> >>
> >>The idea of a exception handling framework looks a good one to me.
> >>The issue
> >>of throws clauses and checked exceptions versus AOP has also been
> >>troubling
> >>me for some time.
> >>
> >>There is some merit in the motivation behind checked exceptions -
> to
> >>ensure
> >>program robustness and reliability in the presence of unpredictable
>
> >>occurrences from the environment and other software components. The
> >>problem
> >>is that Java's mechanism of tackling this enforces code tangling,
> >>exactly
> >>what AOP is meant to avoid.
> >>
> >>I think there is a certain tension between checked exceptions and
> >>AOP.
> >>Aspects have the potential to modularise the issuing / handling of
> >>exceptions just like any other crosscutting concern. It's just that
> >>the
> >>"throws Exception" rule keeps getting in the way. I find it a bit
> >>funny that
> >>AOP's most widely used language includes a mechanism that enforces
> a
> >>crosscutting concern into its code.
> >>
> >>IMHO the AspectJ team should one of these days tackle this problem.
> >>The ajc
> >>compiler could stop generating error messages due to missing
> >>try-catch
> >>blocks. ajc could even provide a switch to re-activate the enforced
>
> >>try-catch (perhaps for mission-critical software), just like javac
> >>does with
> >>the assert statement. After all, AspectJ already enables several
> >>things that
> >>are forbidden by straight Java - privileged aspects are one good
> >>example.
> >>Perhaps AspectJ could provide something along these lines in order
> to
> >>avoid
> >>all those try-catch blocks.
> >>
> >> --
> >>Miguel J. T. Pessoa Monteiro
> >>Ph.D. student Minho University, Portugal
> >>eMail: mmonteiro@xxxxxxxxxxxx
> >>URL: http://gec.di.uminho.pt/mpm/
> >>
> >>_______________________________________________
> >>aspectj-users mailing list
> >>aspectj-users@xxxxxxxxxxx
> >>http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
