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