"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> just a quick question: I posted comments for two checkins lately: One
> about that ugly != null checking by jmcnally which I voted down,
John has been heads-down on Scarab (with me and the rest of the team)
trying to get a release out for our biggest client -- we're about
done, so I'm sure he'll get back to ya soon, Henning. (I realize that
that's not your point, just an FYI.)
I didn't feel really strongly about the change either way, so didn't
comment.
> 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).
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
