From: "Torsten Curdt" <[EMAIL PROTECTED]> > > XSLT Transformer is obviously one of the most popular Cocoon components. > > As such it carries the extra burden of serving as example to people writing > > other components. > > > > In the sake of fairness, exception reporting is much friendlier in 2.1 than > > before. However much remains to be improved. > > > > I was wondering if someone else shares my observations and thinks it's time > > to lay out a design for better exception reporting infrastructure. > > I just stumbled over the same thing... see > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102138232910486&w=2 > > ...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: http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/com ponents/notification/ > 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 to > 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 is > > 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 is > > 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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
