Just a Thought...

A third approach uses a Null Object pattern and a special method.

Suppose the Location class has, in addition to each “find” method, a matching “orElseFind” method that simply returns “this”:

public Location orElseFind(String what) {
    return this;
}

Now create a subclass of Location called NullLocation, which overrides each “orElseFind” method to call the related “find” method in the base class:

class NullLocation extends Location {
    public Location orElseFind(String what) {
        return find(what);
    }
}

Now our client code can look like this:

Location location=Location.find(routingNumber).orElseFind(addressName);

You can chain as many “orElseFind” calls on as you’d like. If anything is found, the following orElseFind invocations just return what was already found. Until something is found, each orElseFind invocation executes the matching find call.

Maybe you’d want to add a simple “boolean isNull()” method to both classes to make it easier to test for a failure.

[Details: Of course, the “find” code in the Location class must return an instance of NullLocation in the event of failure. A singleton instance of NullLocation is appropriate. I’ve left the NullLocation class non-public as it probably would only be referenced by the Location class.]

A more elegant version of this is used in functional programming languages like Haskell and Scala. In those languages, a single “orElse” method that takes a functor or closure is all that’s needed. Alas, in Java the coding of the closure is currently about as painful as all of that try/catch stuff.

The clumsiness in the first example comes from the fact that you’re switching from using exceptions to null return values. It’s much cleaner if you stick with a single paradigm, like this:

// From an address object
Location getLocation() throws LocationNotFoundException
{
    try
    {
        return Location.find(routingNumber);
    }
    catch(LocationNotFoundException lnfe)
    {
        return Location.find(addressName);
    }
}

Jukka Zitting, you are correct that sticking with the same paradigm is better in this little snippet of the code. However, in the context of where the snippet came from it’s not such a hot idea. It was found in the midst of some parsing code. The parser handled a message type that had two opportunities to get the correct location. Once was in the addressees, where this snippet was found, and later in the message where it lists the city it came from. It would be wrong to propagate the exception up to the parser level where the message would then be considered corrupt if it didn’t have the second shot at things. A more accurate example of what was happening was like this:

// From the message object
void addAddress(Address address)
{
    addresses.add(address);

    if ( "FROM".equals( address.getType() )
    {
         Location location = address.getLocation();

         if ( null == location )
         {
             setOriginationName( address.getLocationName() );
         }
         else
         {
             setOrigination( location );
         }
    }
}

I can still see how that can be cleaned up further. Of course, from the puerile standpoint you shouldn’t use exceptions to perform alternate flows. From a performance standpoint, exceptions are much slower than if/else checks with nulls. However, if the Address object did throw an exception it would make the code a little more compact:

// From the message object
void addAddress(Address address)
{
    addresses.add(address);

    if ( "FROM".equals( address.getType() )
    {
         try
         {
             setOrigination( address.getLocation() );
         }
         catch(LocationNotFoundException lnfe)
         {
             setOriginationName( address.getLocationName() );
         }
    }
}

Either way, it’s still not pretty.

Thanks for the context. I agree that the business logic in this case is better handled with normal control flow instead of exceptions. If it’s not exceptional for Location.find() not to find a matching location, then it shouldn’t throw exceptions in such cases. Of course, truly exceptional situations like database connection errors should IMHO still be handled with declared exceptions.

If you want to avoid null references and don’t want to go as far as Doug with dynamic orElseFind() lookups, you could use a special Location.UNKNOWN Null Object like this:

// From an address object
Location getLocation()
{
    Location location = Location.find(routingNumber);

    if ( Location.UNKNOWN == location )
    {
        location = Location.find(addressName);
    }

    return location;
}

Exceptions can carry a lot of information about the error condition. If you can’t put any useful information in an exception, or if the caller just doesn’t get a real benefit from an exception, a null return value is good enough.

Methods named findXXX can always return null because that’s what find means: there’s the possibility that no results will be returned. Methods named getXXX ought to throw exceptions since there the intention to retrieve is much more significant.