cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <>
Subject [RT] Cocoon Exception Handling Infrastructure
Date Tue, 21 May 2002 02:09:50 GMT



over the last few weeks I have gathered some experience working with Cocoon.

There was one obstacle along the way which ranked a distant first compared
to any other.

This obstacle is Cocoon's exception reporting.

Many times exceptions thrown in a component will result in a seemingly
unrelated exception in the browser window. This was really hard for me to
deal with until I got used to searching through all log files until I found
the root cause.
Even basic things like syntax errors in XSL files will report funny output
"Unable to get transformer handler for someXYZ.xsl"
and exception message: java.lang.NullPointerException
The full stack trace is not very helpful either. It dumps lines and lines of
trace information pointing to the code where the XSLT processor threw the
The actual error was that I renamed a xsl:copy-of tag to xsl:copy-of1.
Nothing in the report pointed to this simple problem.

I can probably assume correctly that all developers are expecting from their
interpreters and compilers to pinpoint syntax errors at the very minimum.

Should we blame the XSLT processor for bad exception reporting or Cocoon
just doesn't use all the information it provides concerning processing


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




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

View raw message