To give an example of this scenario, if you call getMarriedPersons toI see your point. In the first case if get a married person and then you don't have a spouse for it. You have a logical exception.
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.
However I sill have to argue. In general, it is nothing exceptional for a person not to have a spouse. By throwing one I think you are adding a functionality that should not be there for the object.
Nothing prevents you from testing hasSpouse() before using getSpouse() if there is no exception - for the general case. And nothing prevents you from throwing an exception after you see there's no spouse - for the particular case of object that should have one.
On Mon, 2005-10-24 at 19:03 -0500, Dawson, Michael wrote:
Take this function call, for example: #parseDateTime("M!ke")#Yes M!ke, in those 2 case you have exceptions. First because the expected format is not respected. Second because there is no database server available. You expect one to be there and you can't have any idea of what has happened without an exception that goes through all the details from the driver (it may be that the database server is shut down, it is overloaded, there's no route to host, etc).
I can't imagine creating a database-related function that returns "0" or "" if the database server was unavailable. That is just flat-out lying to the client code.
However, if your application expects only dates that are greater than let's say 01/01/2005, the function parseDate("12/31/2004") should not raise an exception, it should still return the right date. It is up to you to check the validity of the returned date. Why? Because you can reuse the function parseDate() in other applications that do not have your date constraint.
On Mon, 2005-10-24 at 08:09 -0700, Sean Corfield wrote:
Just remember that a "most used practice" is not necessarily a good practice.I totally agree. Let's give a simple example related to the spouse case. Say you just want to display a list of persons with the related spouses. If getSpouse() returns a NullObject you can ask you gateway getPersons(), then loop over the result and simply display person.getName() and person.getSpouse().getName() without any additional checking, exception or try/catch blocks. Your code is simple, clean and does the job. This is why I tend to prefer the "less used practice" of the NullObject pattern instead of returning a simple null. ----------------------------------------------------------
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]
