db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Poeschl <mpoes...@marmot.at>
Subject IOException -> SAXException (was: Developer communication)
Date Thu, 31 Jul 2003 18:29:12 GMT
let's take a look at the jdk1.4.x sources:
    /**
     * Resolve an external entity.
     *
     * <p>Always return null, so that the parser will use the system
     * identifier provided in the XML document.  This method implements
     * the SAX default behaviour: application writers can override it
     * in a subclass to do special translations such as catalog lookups
     * or URI redirection.</p>
     *
     * @param publicId The public identifer, or null if none is
     *                 available.
     * @param systemId The system identifier provided in the XML
     *                 document.
     * @return The new input source, or null to require the
     *         default behaviour.
     * @exception java.io.IOException If there is an error setting
     *            up the new input source.
     * @exception org.xml.sax.SAXException Any SAX exception, possibly
     *            wrapping another exception.
     * @see org.xml.sax.EntityResolver#resolveEntity
     */
    public InputSource resolveEntity (String publicId, String systemId)
//     throws IOException, SAXException
    throws SAXException
    {
    return null;
    }
 

hmmmm .... so let's look at the sources at sax.sf.net

    *public* InputSource resolveEntity (String publicId, String systemId)
	*throws* IOException, SAXException
    {
	*return* *null*;
    }

the IOException was introduced in sax 2.0 ..

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sax/sax2/src/org/xml/sax/helpers/DefaultHandler.java.diff?r1=1.1&r2=1.2

i prefere to keep the change

martin


Daniel Rall wrote:

>"Henning P. Schmiedehausen" <hps@intermeta.de> writes:
>  
>
>>the other about the IOException -> SAXException change by Martin
>>which I still consider unncecessary because the IOException is
>>allowed by the interface and just because "Eclipse says, this is a
>>bug" changing a valid statement is not really an explanation to me.
>>    
>>
>
>--- XmlToAppData.java	25 Jul 2003 16:39:07 -0000	1.4
>+++ XmlToAppData.java	28 Jul 2003 20:19:02 -0000	1.6
>@@ -219,10 +215,16 @@
>      * @return an InputSource for the database.dtd file
>      */
>     public InputSource resolveEntity(String publicId, String systemId)
>-            throws SAXException,
>-                   IOException
>+            throws SAXException
>     {
>-        return new DTDResolver().resolveEntity(publicId, systemId);
>+		try 
>+		{
>+			return new DTDResolver().resolveEntity(publicId, systemId);
>+		} 
>+		catch (Exception e) 
>+		{
>+			throw new SAXException(e);
>+		}
>     }
> 
>
>Leaving both IOException and SAXException in the "throws" declaration
>of resolveEntity() provides the most flexible extensionability of
>XmlToAppData without introducing additional complexity (by merely
>conforming to an extant API).
>
>I can't say that wrapping IOException in a SAXException when the API
>allows for IOExceptions to be thrown makes much sense to me, and would
>prefer that the change be reverted (no offense Martin).
>  
>



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


Mime
View raw message