cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [RT] Cocoon Exception Handling Infrastructure
Date Tue, 21 May 2002 08:23:37 GMT
From: "Torsten Curdt" <>

> > XSLT Transformer is obviously one of the most popular Cocoon components.
> > As such it carries the extra burden of serving as example to people
> > other components.
> >
> > In the sake of fairness, exception reporting is much friendlier in 2.1
> > before. However much remains to be improved.
> >
> > I was wondering if someone else shares my observations and thinks it's
> > to lay out a design for better exception reporting infrastructure.
> I just stumbled over the same thing... see
> ...altough this was a more technical issue - unfortunately noone responded
> I think we should really make sure there is really a single of point of
> failure where the exceptions bubble up and where it is defined if they are
> presented to the user or not. (This should be configurable since error
> reporting can also be security issue when it comes to deployment)

Well, there is () , but Cocoon still suffers from the legacy way of wrapping
all exceptions in ProcessingExceptions.
Components should not catch exceptions unless they can correctly rethrow a
more detailed version, and cascade the exception.

notification system:

> To have a more useful output than just a stacktrace I have modified the
> LanguageException to present the error part of an failed XSP compilation
> the user as you (might have noticed). Of course this is only useful for
> developement but it should lower the barrier for newbies...

Yeah, cool :-D

> > I think that one of the biggest psychological barriers for Cocoon users
> > that they can't easily start writing simple apps. Cocoon is not very
> > forgiving with bad input, while at the same time its exception reporting
> > often misleading the developer instead of pinpointing the problem.
> exactly...

I fixed the XSLT Transformer problem some time back, but it keeps on coming
back and then going away.

Component programmers must be aware that how they throw things *matters*.

Any suggestions on how to "enforce" this?
My original intention was to warn the user that the programmer overlooked
the proper handling if the Exception didn't implement "Notifying", but I'm
not sure...

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message