cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: avalon.ComponentNotAccessibleException
Date Fri, 15 Sep 2000 05:58:16 GMT

----- Original Message ----- 
From: "Peter Donald" <donaldp@mad.scientist.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, September 15, 2000 7:13 AM
Subject: Re: avalon.ComponentNotAccessibleException


> 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.
> 
> >> 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;
> }
> 
> Then at top level do some generic exception handling.

Read carefullly ONLY to rethrow them. :-)
You also do checking.

> This allows you some of the benefits of aspect-orientated exception
> handling but keeps it standard java and eases debugging.

True, in fact this is what I say after.

> >> 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.

Here it is. And now I add... (from you :-) ) "and as long as you do local
decisions based on the error".

> >> 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.
> 
> 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 ?

As I said to Stefano, wait two days (damn, I'm in the middle of my exam
sasssion :-( ) and I will send a test version that does all this.
Anyway FNO I will continue the discussion on the Avalon list, if
I find how to subscribe :-)

nicola_ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)


Mime
View raw message