On 5/12/05, Hal Helms <[EMAIL PROTECTED]> wrote: > Here's a common case: I have an object of type, Human, with an instance > variable, "spouse", of type, Human. Now, if I call the getSpouse() method > (that rightly advertises that it returns a Human) on a single person, what > will I get? I might, in some circumstances, be able to create a sort of > "empty Human" but at other times, business rules will prohibit me from doing > this. That's why interfaces would be really, really good, but null is > mandatory.
Why would you call getSpouse() on a Human that doesn't have a spouse? Why would you have getSpouse() return null if the Human's not married? That's just asking for a NullPointerException. Given than NullObject has been taken off the table, I would opt to have getSpouse() throw an exception if the human isn't married. And I would add an isMarried() function so I can check before calling getSpouse(). I'd rather proactively check that a person is married before calling getSpouse() than reactively check that getSpouse() didn't return null. And if I forget to check, I'd rather debug a HeyDummyIDontHaveASpouse exception thrown by Human.getSpouse() than a NullPointerException thrown by some other CFC that's miles away from the problem. Am I missing something here? Is there ever a good reason for a function to return null? Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
