DO NOT REPLY [Bug 717] - quiet swallowing of exceptions

[bu...@apache.org]

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

minchau@ca.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From minchau@ca.ibm.com  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