Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39C23265.54089B3@apache.org>
Date: Fri, 15 Sep 2000 16:29:57 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: avalon.ComponentNotAccessibleException
References: <20000914.6504900@sahuc-s.imediation.com>
	 <39C0D318.9BD4F10F@apache.org>
	 <00dd01c01e59$5bf50200$be022397@ARES>
 <3.0.6.32.20000915151348.00eabea0@latcs2.cs.latrobe.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
nestable.
 
> 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------