Ola Berg wrote:
>>Actually the exceptions are wrapped but unfortunately there is no
>>evaluation of all possible wrapping exceptions at the top level.
>
> [...snip...]
>
> Yes, I know. I\'ve been following the discussions re nested
> exceptions at jakarta-commons, as well as in two client project,
> and there seem to be little or no consensus on what would be the
> \"best practise\".
>
> It doesn\'t help my use-case though. It would be very helpful if the
> parser\'s exceptions included information on what resource it
> attempted to parse.
It should now IIRC, it got patched... :-?
> I suspect that this is a thing that hinders people from coming up
> to speed with Cocoon. And if there is too much initial investment
> to do in time, corporate users (you know: the \"normal\" guys who
> only does hacking at paid day-time, not perverts like us :-)
> will not use the tool.
>
> Debugging Cocoon apps is an issue. People are used to
> trial-and-error methods of learning. Then it would be nice
> to see where the error is. When doing my first C2 installation
> two months ago, I spent a week debugging my XML source, when the
> error was a minor one in the site map. Add XSLT-sheets
> and the complexity grows.
No developer in Cocoon except me and Sylvain really has ever been
interested in error reporting.
It became my first itch with Cocoon, since with 1.0 you never knew how
the installation had failed.
I did my best, and it worked, but things inside Cocoon keep breaking it.
I cannot do anything if an exception is caught or rethrown badly,
unfortunately it's the component that has to do it properly, and
XSLTTransformer for example was patched loads of times for this.
> One problem is that as one gets more experienced with the tool,
> one will see the errors less often, so it will never
> become an itch to scratch. When you are confident with the tool
> enough to hack it, you don\'t have the same needs that
> you\'ve had when you were a beginner, so the tool will never
> become beginner-friendly.
Yup.
> In order to overcome this, I have started to scribble down my initial
> stupid beginner mistakes. If Cocoon would catch those and spit out
> intelligent messages and suggestions, the tool would be better.
Good, let's do it then.
I have started doing it many times i9n the past and it always got broken
after some time, but now users are complaining, my friends are
complaining, you are rightly having problems...
What we need are UNIT TESTS for the error stuff.
TESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTS
TESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTS
TESTSTESTSTESTSTESTS T E S T S ESTSTESTSTESTSTESTS
TESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTS
TESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTSTESTS
If we don't write them, developers will break the error stuff without
even knowing, and I get all the blame ;-)
Your suggestions you talk about are verry helpful; if you are able also
to write test cases (or suggest them in detail), we could set them up
and have them always evaluated.
-oOo-
Also, Cocoon.java error handling is currently undefined.
When it encounters a problem, it sometimes returns null, sometimes go
silent, and sometimes throw an error.
What should it do in case it doesn't use a <handle-errors>?
My idea is that it should rethrow the exception.
--
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]
