W3C home > Mailing lists > Public > www-dom-ts@w3.org > October 2001

Should an method throw an exception not defined in the spec (was: isSupported12.xml)

From: Curt Arnold <carnold@houston.rr.com>
Date: Fri, 26 Oct 2001 00:29:55 -0500
Message-ID: <000701c15ddf$3f2e3e90$7600a8c0@CurtMicron>
To: <www-dom-ts@w3.org>
Cc: <www-dom@w3.org>
This is a continuation of an www-dom-ts discussion on whether it would be
allowable for an implementation of node.isSupported to throw an exception
if, for example, the feature name is not an XML name even though the spec
says "No exceptions".

For some background,
http://java.sun.com/docs/books/tutorial/essential/exceptions/catchOrDeclare.
html
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

Now to the text of Exception DOMException:

The first paragraph, "DOM exceptions only...", is a  general design
principle.  It says the design of DOM prefers to return error values unless
things are seriously wrong.  The example sited is that
nodeList.item(nodeList.length) returns null instead of throwing an out of
bound exception.

The second paragraph (as clarified in errata core-15) could still be
clearer:
Implementations should raise other exceptions under other circumstances. For
example, implementations should raise an implementation-dependent exception
if a null argument is passed when null was not expected.

I would not interpret this as a license for implementations to intentionally
throw exceptions that are not explicitly defined in the spec, but as an
acknowledgement that what would be called a RuntimeExceptions on the Java
platform, such as the mentioned NullPointerException, SecurityException, out
of memory exceptions, etc, might occur without an explicit attempt to raise
an exception on the part of the implementation.  (I think the perceived
intent would be better expressed if "should" were "can" and "other" were
"unanticipated")

For a Java implementation to raise an "implementation-dependent exception"
because the feature is not a valid XML name, the implementer would have to
violate both the DOM design principal mentioned in the first paragraph
(since it is choosing to throw an exception when returning false is
adequate) and to purposefully create an RuntimeException for an explicitly
thrown exception not in runtime code (otherwise the Java compiler would
report an error in throwing a checked exception that was not declared in the
method).

Most other platforms/languages would not enforce the prohibition on throwing
undeclared exceptions, however the principal should still be in effect, you
don't surprise a caller with an exception that you didn't tell them to
expect.
Received on Friday, 26 October 2001 01:31:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:45 GMT