You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Nathan Beyer (JIRA)" <xe...@xml.apache.org> on 2006/01/21 01:57:42 UTC

[jira] Updated: (XERCESJ-444) SAXException thrown by EntityResolver is reported as IOException

     [ http://issues.apache.org/jira/browse/XERCESJ-444?page=all ]

Nathan Beyer updated XERCESJ-444:
---------------------------------

    Attachment: jira_444_patch.txt
                ExceptionBuilder.java
                jira_444_alt_patch.txt

This patch should resolve the issue, as well as make SAXException to XNIException wrapper a little more consistent. The "jira_444_patch.txt" contains a diff of the files that changed, which includes EntityResolverWrapper, EntityResolver2Wrapper, ErrorHandlerProxy and ErrorHandlerWrapper. The "ExceptionBuilder.jar" is a new package-private class that all of the change classes now use.

If this patch is too much or not desirable, the file "jira_444_alt_patch.txt" contains a much simpler fix and only affect the two EntityResolver classes.

> SAXException thrown by EntityResolver is reported as IOException
> ----------------------------------------------------------------
>
>          Key: XERCESJ-444
>          URL: http://issues.apache.org/jira/browse/XERCESJ-444
>      Project: Xerces2-J
>         Type: Bug
>   Components: SAX
>     Versions: 2.0.2
>  Environment: Operating System: Windows XP
> Platform: PC
>     Reporter: Kohsuke Kawaguchi
>     Assignee: Xerces-J Developers Mailing List
>  Attachments: ExceptionBuilder.java, jira_444_alt_patch.txt, jira_444_patch.txt
>
> If I throw a SAXException that has an IOException as its nested exception from 
> EntityResolver, the parser will report it as IOException, not as SAXException.
> Here is what happens. The SAXException thrown by an EntityResolver is first 
> catched by org.apache.xerces.utilEntityResolverWrapper. The following code is 
> in the catch block
> >            // error resolving entity
> >            catch (SAXException e) {
> >                Exception ex = e.getException();
> >                if (ex == null) {
> >                    ex = e;
> >                }
> >                throw new XNIException(ex);
> >            }
> Since the SAXException I throw has a nested exception, an XNIException with 
> nested IOException will be re-thrown from here.
> This exception will be relayed by several components, and eventually it will 
> come to the parse method of the org.apache.xerces.parsers.AbstractSAXParser 
> class.
> (line.1194)
> >        catch (XNIException e) {
> >            Exception ex = e.getException();
> >            if (ex == null) {
> >                throw new SAXException(e.getMessage());
> >            }
> >            if (ex instanceof SAXException) {
> >                throw (SAXException)ex;
> >            }
> >            if (ex instanceof IOException) {
> >                throw (IOException)ex;
> >            }
> >            throw new SAXException(ex);
> >        }
> Since the nested exception is IOException, it will be thrown as IOException.
> The net effect is that my application handler will receive an IOException even 
> though I threw a SAXException.
> I believe this is a bug; I should receive what I threw.
> It seems to me that the bug is in the catch block of EntityResolverWrapper. It 
> should just wrap the SAXException into XNIException, instead of trying to 
> unwrap it. So the code should be just:
> // error resolving entity
> catch (SAXException e) {
>     throw new XNIException(e);
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org