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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
