Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39C125D1.C20BFCD8@apache.org>
Date: Thu, 14 Sep 2000 21:24:01 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: Avalon <java-apache-framework@list.working-dogs.com>
CC: cocoon-dev@xml.apache.org
Subject: Re: avalon.ComponentNotAccessibleException
References: <20000914.6504900@sahuc-s.imediation.com>
 <39C0D318.9BD4F10F@apache.org> <00dd01c01e59$5bf50200$be022397@ARES>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nicola Ken Barozzi wrote:
> 
> ----- Original Message -----
> From: "Stefano Mazzocchi" <stefano@apache.org>
> To: <cocoon-dev@xml.apache.org>
> Sent: Thursday, September 14, 2000 3:31 PM
> Subject: Re: avalon.ComponentNotAccessibleException
> 
> > Sebastien Sahuc wrote:
> > >
> > > I got the EXACT same problem by using Tomcat 3.3dev anf putting all
> > > cocoon jar in web-inf/lib.
> >
> > yes, Pier and I are currently chasing this down, stay tuned for news.
> >
> > > Didn't try by setting a global classpath, I switched back to resin !
> >
> > If you place everything in the system classpath it works, but this is
> > NOT what we want: we want classpath-free installation. Drop the
> > Cocoon.war and you're done. Period. Nothing more. Nada. Zip.
> >
> > > It seems at least that the error message isn't explicit enough. There
> > > should be somehow a short explanation on which compoenent it failed to
> > > load instead of a [null, null]... :-)
> >
> > I feel bad to say this... but Ricardo's way of catching exception is a
> > total nightmare... I need to go thru all of C2 code to create a solid
> > exception handling framework... we can't continue to catch exception and
> > rethrow them encapsulated , this is plain silly.

Like I told you on the phone (but it's unfair to have such private
conversations even if the bandwidth is much higher), I think a more
general exception framework is needed.

And this implies making this an Avalon thing.

> Stefano, if you say -go- I will try to mend these problems.

I say "go on the Avalon list" :)

> A simple way is that whoever throws an error is invited to
> throw one that implements the Notifiable interface, which has
> the capability of extended explanations.

the problem is not about lack of explanation, but the fact that if you
do

 public myMethod() throws NotifiableException {
  try {
    // bunch of stuff
  } catch (Exception e) {
    throw new NotifiableException("lots of details");
  }
 }

it's much less useful than do

 public myMethod() throws Exception {
   // bunch of stuff
 }

since you loose the stack trace.

A good exception-handling framework is given by SAXException which is a
cascading exception... 

  public class CascadingException extends Exception {
     private Exception exception;
     public CascadingException(String message) {
       this(message, null);
     }
     public CascadingException(Exception e) {
       this(null, e);
     }
     public CascadingException(String message, Exception e) {
       super(message);
       this.exception = e;
     }
     public String getMessage() {
	String message = super.getMessage();
	if (message == null && exception != null) {
	    return exception.getMessage();
	} else {
	    return message;
	}
     }
     public String getMessage() {
	String message = super.getMessage();
	if (message == null && exception != null) {
	    return exception.getMessage();
	} else {
	    return message;
	}
     }
     public String getLocalizedMessage() {
	String message = super.getLocalizedMessage();
	if (message == null && exception != null) {
	    return exception.getLocalizedMessage();
	} else {
	    return message;
	}
     }
     public String toString() {
	if (exception != null) {
	    return exception.toString();
	} else {
	    return super.toString();
 	}
     }
     public Exception getException() {
        return exception;
     }
  }

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

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

This is the kind of discussion that happen in the Avalon mail list.

Please, let's continue it overthere.

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