Actually, I propose the additional:
1. JellySAXException extends SAXException
2. JellySAXParseException extends SAXParseException
With the overridden toString() method.
-Kevin
-----Original Message-----
From: Kevin Ross [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 11:47 AM
To: [EMAIL PROTECTED]
Subject: [jelly] XMLParser exception patch
I've run into a few issues where I make mistakes in my script, namely
bad jexl expressions in attributes. Exception stacks where somewhat
incomprehensible, and no line number was present, when I know the fine
Jelly code has it somewhere ;)
I've removed a few calls to log.warn, where useful messages where there,
but not in the exception message (now added). Also, I have removed one
call to e.printStackTrace(). These were definitely removed to reduce
logging, enable the exception to have the full context, and allow the
caller to log or throw as they wish.
On the issue of visibility, I have found a crazy qwerk in the
SAXException.toString() when a cause (exception) is added to it. It
simply forgets it's message by calling (internally)
getException().toString() (equivalent to jdk1.4 getCause().toString()).
To properly see the message from the SAXException, including
SAXParseException, you must explicitly call SAXException.getMessage() +
SAXException.toString(). This is probably why these other log
statements were placed there.
I have not done this yet, but I additionally propose we add a
JellyParseException (extends SAXParseException) that will override this
behavior and toString() properly, and change this in XMLParser. I would
be glad to do so if the commiters are on board.
Kevin Ross
PS- in the patch-diff, I left the old lines commented. Is it
conventional to do so, or just make my changes?
