cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: avalon.ComponentNotAccessibleException
Date Fri, 15 Sep 2000 14:29:57 GMT
Peter Donald wrote:
> At 09:24  14/9/00 +0200, you wrote:
> >A good exception-handling framework is given by SAXException which is a
> >cascading exception...
> Just FYI a future version of Java will have this functionality built into
> throwable.

Uh, really? good to know.. thanks.
> >> A notification logger with levels (warning, debug, etc) like the
> >> C1 logger is needed to work in conjunction with notifications.
> >>
> >> Anyway I guess you have in mind a more generic error-handling
> >> framework... but Java ha its own, and it works well, IMHO.
> >
> >Well, I would have made Exception an interface... but this is because I
> >love interfaces :)
> >
> >> If you catch errors only to rethrow them, you have a design problem.
> >
> >Yes, exactly.
> I disagree.
> In many cases my code wll look like the following
> try
> {
> ...
> }
> catch( final Throwable t )
> {
>   if( LOG ) LOGGER.warn("Error occured", t );
>   throw t;
> }

Ehmmm, you are NOT just catching to rethrow: you are *doing* something
here, log it! Big difference.

Ken and I agree that something like

 method blah() throws BlahException {
  try {
   // my method stuff
  } catch {Exception e) {
    throw new BlahException(e.getMessage());

is DEAD WRONG and clearly indicates a design problem (the method should
throw Exception rather than BlahException)... or BlahException should be
> Then at top level do some generic exception handling.
> This allows you some of the benefits of aspect-orientated exception
> handling but keeps it standard java and eases debugging.

Sure it does, but in our case you loose the stacktrace and your
debugging becomes a nightmare!!!
> >> But errors should be more documented: if errors have to be encapsulated
> >> to be sent it's not bad at all, as long as you do it in a class that needs
> >> a description to get going.
> >>
> >> In practice, we need a sort on SAX Wrapper interface that accepts
> >> NotificableExceptions instead of SAX Exceptions.
> >> But this is a big mess, I think.
> >>
> >> So _final proposal_ (I) make a SAXNotifiableException that implements
> >> Notifiable. When you rethrow you add info, and you can throw it
> >> as a SAXException, no need to change interfaces.
> >> Just have to check in Notifier if it's also instanceOf Notifiable.
> >> BTW, if logging is added, shouldn't error handling become a component?
> I would prefer to have a base class from which exceptions extend and then
> manipulate that.

This is exactly what I meant (see below).
> ie I would like to see a class either AvalonException or CascadingException
> that kept reference to root exception. (Actually if you search the archives
> that was what I was hinting at re: init() exception handling :P). Both
> Avalon and I suspect C2 allow throwing of raw undecorated exceptions which
> I really don't like :(. I planned to redo AValon side to be safer in future
> but could probably do it now if C2 needs it :P
> So what are your thoughts on this ?

See my recent proposal on the Avalon mail list.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message