Comments on: Why Methods Should Check Their Arguments http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/ Longer than a blog; shorter than a book Wed, 08 Feb 2012 21:45:25 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: Anonymouse http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-27308 Anonymouse Sun, 05 Nov 2006 02:39:50 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-27308 Stronger typing won't help (in all cases.) So you should validate your arguments. Which means you don't even need strong typing. Stronger typing won’t help (in all cases.) So you should validate your arguments. Which means you don’t even need strong typing.

]]> By: Elliotte Rusty Harold http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-4704 Elliotte Rusty Harold Tue, 27 Jun 2006 01:03:26 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-4704 XOM does throw an exception if the XPath you pass in is syntactically incorrect. Your bug was that you used a legal XPath expression that happened to not be the XPath expression you really wanted. I don't think XOM can read your mind to guess what you really meant to do. :-) XOM does throw an exception if the XPath you pass in is syntactically incorrect. Your bug was that you used a legal XPath expression that happened to not be the XPath expression you really wanted. I don’t think XOM can read your mind to guess what you really meant to do. :-)

]]> By: Paul Campbell http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-4546 Paul Campbell Fri, 23 Jun 2006 22:41:14 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-4546 I have just been chasing a similiar problem although simpler problem in Node.query(String xpath) this afternoon. I failed to start my query with // and it kept returning Nodes.size() = 0. Previously, I had hardcoded my query String and had it working and then switched to passing an argument which was mis-coded. It would be nice if Node would throw an exception if it receives faulty xpath syntax. PS: Would you consider adding the sample XOM/src/nu/xom/samples/XPathDriver.java to http://www.xom.nu/samples.xhtml Thanks I have just been chasing a similiar problem although simpler problem in Node.query(String xpath) this afternoon.
I failed to start my query with // and it kept returning Nodes.size() = 0.

Previously, I had hardcoded my query String and had it working
and then switched to passing an argument which was mis-coded.
It would be nice if Node would throw an exception if it receives
faulty xpath syntax.

PS: Would you consider adding the sample
XOM/src/nu/xom/samples/XPathDriver.java
to http://www.xom.nu/samples.xhtml
Thanks

]]> By: 果冻帝国 » Daily Reading Summary - Tech http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-4226 果冻帝国 » Daily Reading Summary - Tech Mon, 19 Jun 2006 16:59:23 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-4226 [...] [-[1]-] I just read this Why Methods Should Check Their Arguments by Elliotte Rusty Harold. I had an almost identical issue a few weeks ago. [...] [...] [-[1]-] I just read this Why Methods Should Check Their Arguments by Elliotte Rusty Harold. I had an almost identical issue a few weeks ago. [...]

]]> By: Elliotte Rusty Harold http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-4062 Elliotte Rusty Harold Fri, 16 Jun 2006 10:44:08 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-4062 Relative URLs are not correct in QNames. No infoset is defined for such documents. (The W3C spent a lot of time sorting this one out circa 2000.) Relative URLs should be rejected by this class, even in the right position. Relative URLs are not correct in QNames. No infoset is defined for such documents. (The W3C spent a lot of time sorting this one out circa 2000.) Relative URLs should be rejected by this class, even in the right position.

]]> By: Chris Burdess http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-4060 Chris Burdess Fri, 16 Jun 2006 10:14:26 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-4060 Even if the QName class went to all the effort of lexically validating its arguments you could still find combinations of relative URLs and local-names that would pass this validation in the wrong parameter position. So I don't personally feel that the extra effort of validation is worth it, especially in a method that is called a *lot*. Sometimes you really just have to be familiar with an API, and it's just unfortunate that the cost of that familiarity is hours spent debugging. Even if the QName class went to all the effort of lexically validating its arguments you could still find combinations of relative URLs and local-names that would pass this validation in the wrong parameter position. So I don’t personally feel that the extra effort of validation is worth it, especially in a method that is called a *lot*. Sometimes you really just have to be familiar with an API, and it’s just unfortunate that the cost of that familiarity is hours spent debugging.

]]> By: Elliotte Rusty Harold http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-3993 Elliotte Rusty Harold Thu, 15 Jun 2006 09:27:45 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-3993 The URL object perhaps could have been a <code>java.net.URI</code> object or some custom class. The <code>java.net.URL</code> class carries too much lookup baggage, though. It can't represent an arbitrary absolute URI, just URLs for which Java has an available protocol handler. Also, it's a side point; but it's worth noting that the first argument is <em>not</em> an ISBN number. It's an XML local name which happens to be the string "valid-isbn". You couldn't tell from the limited context I provided, but this is actually the name of an XPath extension function that checks ISBN numbers to see if they're correct. The URL object perhaps could have been a java.net.URI object or some custom class. The java.net.URL class carries too much lookup baggage, though. It can’t represent an arbitrary absolute URI, just URLs for which Java has an available protocol handler.

Also, it’s a side point; but it’s worth noting that the first argument is not an ISBN number. It’s an XML local name which happens to be the string “valid-isbn”. You couldn’t tell from the limited context I provided, but this is actually the name of an XPath extension function that checks ISBN numbers to see if they’re correct.

]]> By: Ted Young http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-3924 Ted Young Thu, 15 Jun 2006 01:22:02 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-3924 I agree with Ian, in that at least the URL argument should have been a URL object. The ISBN is fine as a String, unless there was some mechanism for doing a lookup. Alas, if you do that, you'd probably end up writing a convenience method that took a pair of Strings, turned them into the URL and ISBN objects, and then instantiated QName. And then you'd be back where you started. So, fail early and fail often, especially in constructors. ;ted p.s. Do you think you could turn off the full (left and right) text justification? It makes it harder to read than ragged-right text, especially with code that doesn't line-break well and the lack of hyphenation. I agree with Ian, in that at least the URL argument should have been a URL object. The ISBN is fine as a String, unless there was some mechanism for doing a lookup. Alas, if you do that, you’d probably end up writing a convenience method that took a pair of Strings, turned them into the URL and ISBN objects, and then instantiated QName. And then you’d be back where you started.

So, fail early and fail often, especially in constructors.

;ted

p.s. Do you think you could turn off the full (left and right) text justification? It makes it harder to read than ragged-right text, especially with code that doesn’t line-break well and the lack of hyphenation.

]]> By: Elliotte Rusty Harold http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-3851 Elliotte Rusty Harold Wed, 14 Jun 2006 17:39:01 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-3851 I seriously considered checking arguments in XOM parameterized getters too. (A regular getter has no arguments and thus doesn't need to check them.) My feeling there, though, was that there just weren't quite enough problems to justify the added cost of doing the check in the getters. At least a bad getter argument doesn't corrupt the object, whereas a bad setter or constructor argument does. One thing I did consider and might still implement is lazy getter checking. That is, check the getter arguments only if the parameterized getter fails to find anything. I seriously considered checking arguments in XOM parameterized getters too. (A regular getter has no arguments and thus doesn’t need to check them.) My feeling there, though, was that there just weren’t quite enough problems to justify the added cost of doing the check in the getters. At least a bad getter argument doesn’t corrupt the object, whereas a bad setter or constructor argument does.

One thing I did consider and might still implement is lazy getter checking. That is, check the getter arguments only if the parameterized getter fails to find anything.

]]> By: Elliotte Rusty Harold http://cafe.elharo.com/blogroll/why-methods-should-check-their-arguments/comment-page-1/#comment-3772 Elliotte Rusty Harold Wed, 14 Jun 2006 11:27:16 +0000 http://cafe.elharo.com/java/why-methods-should-check-their-arguments/#comment-3772 Interesting points about named arguments. If I ever get around to designing my own programming language, I'll add them to the list of features to consider. However, in Java as it exists today, there are coding principles that would have avoided this bug. Unfortunately the <code>QName</code> class didn't use them. Interesting points about named arguments. If I ever get around to designing my own programming language, I’ll add them to the list of features to consider. However, in Java as it exists today, there are coding principles that would have avoided this bug. Unfortunately the QName class didn’t use them.

]]>