DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=717>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=717 quiet swallowing of exceptions [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From [EMAIL PROTECTED] 2003-10-18 15:51 ------- I ran the testcase posted by Scott Lamb twice. The first time with RUNTIME=true so that it throws a RuntimeException. Stopping with a debugger just at the throw point the stack looks like this: ---------------------------------------------------------- XalanExceptionBugTester$1.startElement(String, String, String, Attributes) line: 59 TransformerIdentityImpl.startElement(String, String, String, Attributes) line: 1042 SAXParser(AbstractSAXParser).startElement(QName, XMLAttributes, Augmentations) line: not available [local variables unavailable] SAXParser(AbstractXMLDocumentParser).emptyElement(QName, XMLAttributes, Augmentations) line: not available [local variables unavailable] XMLDTDValidator.emptyElement(QName, XMLAttributes, Augmentations) line: not available [local variables unavailable] XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanStartElement() line: not available [local variables unavailable] XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook() line: not available [local variables unavailable] XMLDocumentScannerImpl$ContentDispatcher (XMLDocumentFragmentScannerImpl$FragmentContentDispatcher).dispatch(boolean) line: not available [local variables unavailable] XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) line: not available [local variables unavailable] XML11Configuration.parse(boolean) line: not available [local variables unavailable] XML11Configuration(DTDConfiguration).parse(XMLInputSource) line: not available [local variables unavailable] SAXParser(XMLParser).parse(XMLInputSource) line: not available [local variables unavailable] SAXParser(AbstractSAXParser).parse(InputSource) line: not available [local variables unavailable] XalanExceptionBugTester.main(String[]) line: 125 -------------------------------------------- All of the stack frames were from Xerces except for the oldest and newest ones which were int XalanExceptionBugTester and the second newest stackframe which was one in TransformerImpl in Xalan. Specifically this line was: org.apache.xalan.transformer.TransformerIdentityImpl.startElement (String,String,String,Attributes) and was the last line in that method. public void startElement( String uri, String localName, String qName, Attributes attributes) { // ... there is code here ... // The throw occurs on the next line, the last on in this method . . . m_resultContentHandler.startElement(uri, localName, qName, attributes); } Given that the user code called from this line throws either a RuntimeException or a SAXException and this exception says it "throws SAXException" there is not much that Xalan does with it, it just percolates to pervious stack frames in Xerces and then the users code. Indeed I set a breakpoint in the TransformerImple.postExceptionFromThread() method suggested by the originator of the defect, Patrick Moore but the code is commented out because of a bug reported by Nicola Brown. Barring comments the only thing left in the method is: m_isTransformDone = true; m_exceptionThrown = e; synchronized (this) { notifyAll(); } Setting a breakpoint on "notifyAll();" did not stop, so as the stackframe that I included would indicate, this method is no longer involved. Indeed when the program ran to conclusion the RuntimeException did not get quietly swallowed but was caught by the code inprinted by the user code in XalanExceptionBugTester.main(String[]) : } catch (Exception e) { e.printStackTrace(); } It came out as: ----------------------------------- java.lang.RuntimeException: RuntimeException for XalanExceptionBugTester at XalanExceptionBugTester$1.startElement (XalanExceptionBugTester.java:61) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (TransformerIdentityImpl.java:1043) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement (Unknown Source) at XalanExceptionBugTester.main(XalanExceptionBugTester.java:125) ------------------------------------- Changing the value -------------------------------------- org.xml.sax.SAXParseException: SAXParserException for XalanExceptionBugTester at XalanExceptionBugTester$1.startElement (XalanExceptionBugTester.java:63) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (TransformerIdentityImpl.java:1043) at XalanExceptionBugTester.main(XalanExceptionBugTester.java:125) -------------------------------------- For either exception this is true: - the RuntimeException or SAXException is not quietly swallowed anymore. - Xalan's TransformerImpl.postExceptionFromThread(Exception e) is not involved anymore - The only Xalan method on the stack at the throw point is the last line of TransformerIdentityImpl.startElement...) which will not do anything with the exception but throw it. I don't think this is a bug anymore. If anyone still thinks there still is a problem then please re-open append comments to this bug. Also if there is still a bug we'll move this over to Xerces because Xalan isn't on the stack frame at the throw point except for one trivial stack frame. Regards, Brian Minchau
