- From: Curt Arnold <carnold@houston.rr.com>
- Date: Fri, 26 Oct 2001 00:29:55 -0500
- 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:55 UTC