Tor Norbye wrote: > > I kept getting this exception from the Xerces XML parser, but I > couldn't figure out why. So I downloaded the source code and > examined it, and found that after an exception is thrown by the > user's handler code, a new exception is instead thrown from > the catch clause. By inserting my own printStackTrace of the > original exception, I found my problem immediately.
I have unsuccessfully pointed it out at Xerces dev mailing list. Namely I asked why are runtime exceptions turned into SAXExceptions. [snip] > (P.S. The Xerces library had a PRINT_STACK_TRACE variable or > something like that to enable full stacktraces. When I did that, Then you have to recompile Xerces. Hopefully you can ask SAXException for the original reason by calling getException() without recompiling Xerces. > I got my original stacktrace, but I got LOTS of other exceptions > thrown during NetBeans parsing. I'm assuming this is known and > expected, but I remember from the performance discussions before > that exceptions are bad for performance so I thought I'd mention > it in case nobody had noticed this.) Expected are just those caused by invalid input documents. All others should be reported as bugs either in handler implementation or Xerces parser respectively. Besides under SAX a parser can be stopped just by throwing exception (A lot of reported exceptions should be such intentional STOP exceptions used during XML content sniffing). Cc. -- <address> <a href="mailto:[EMAIL PROTECTED]";>Petr Kuzel</a> at Sun Microsystems : <a href="http://xml.netbeans.org/";>XML module</a> and : <a href="http://jini.netbeans.org/";>Jini</a> developer.</address> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
