So if I have this right then. The best thing for me to do is return the object in getUser, make sure it is defined as an empty object, and wrap the call from the calling template with a hasUser().
Regards Andrew Scott Analyst Programmer CMS Transport Systems Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9699 7988 - Fax: 03 9699 7976 Quote: Time is the best teacher; unfortunately, it kills all its students. ---------------------------------------------------------------------------- -------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Tuesday, 25 October 2005 2:52 AM To: [email protected] Subject: Re: [CFCDev] CFC return types Any time we agree, I consider it a good thing. I was basing it on your "Agreed" to Hal's comment, which is who I was really responding to, but no worries. > Provide a precondition check *if* the > situation is 'expected' so code can explicitly test for the expected > condition but have the 'get' routine throw an exception if the > precondition is not met. To give an example of this scenario, if you call getMarriedPersons to get a collection of Person objects, you could skip the 'hasSpouse' check before calling getSpouse, since you if they don't, it's an exeptional case, and you want the exception to be thrown, even though you could have prevented it. If you just have some random Person object, you'd definitely want to call hasSpouse, because being unmarried is not an exceptional case in that context. cheers, barneyb On 10/24/05, Sean Corfield <[EMAIL PROTECTED]> wrote: > On 10/24/05, Mihai Manuta <[EMAIL PROTECTED]> wrote: > > Given the most used practice in the OOP is to return null (or a NullObject) > > when you don't have anything to return (and you don't have an error, there > > is just nothing there to give back...) it seems only reasonable for other > > developers to expect you to do that. > > There is a strong school of thought in software engineering that > returned values should not be 'unusual', i.e., you should never have > to say "if result is not special, then do something with result". That > school of thought produces code that is not full of return value > checks, but uses either precondition checks or exceptions instead. > That school argues that being forced to check return values everywhere > in your code makes code hard to read and makes code brittle (a single > missing test likely leads to subtle failure or, if you're lucky, an > exception). That school never uses "" as a special string return, > never uses 0 or -1 as a special numeric return and would never return > null when a real object is required. > > Just remember that a "most used practice" is not necessarily a good practice. > > I'm actually in agreement with Barney on this (despite him saying he > disagrees with me! - I think if he disagrees with Hal then he also > disagrees with Vince, not me). Provide a precondition check *if* the > situation is 'expected' so code can explicitly test for the expected > condition but have the 'get' routine throw an exception if the > precondition is not met. > -- > Sean A Corfield -- http://corfield.org/ > Got frameworks? > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
