How Can I Avoid Using Exceptions for Flow Control?

Question

I have been assigned a project to develop a set of classes that act as an interface to a storage system. A requirement is that the class support a get method with the follo

Answer 1

You could follow the .Net library pattern of and have a public static readonly field in the custom object called CustomObject.Empty that is of type CustomObject (like string.Empty and Guid.Empty). You could return this if the object is not modified (the function consumer will need to compare against it).
Edit: I only just spotted that you're working in Java, but the principle still applies

This gives you the option of the following

• Return null if the key doesn't exist.

• Return CustomObject.Empty if the key exists but the object has not been modified.

The drawback is that the consumer would need to know the difference between a null return value and a CustomObject.Empty return value.

Perhaps the property would be more aptly called CustomObject.NotModified as Empty is really intended for Value types as they cannot be null. Also NotModified would convey the meaning of the field more easily to the consumer.

Answer 2

Looking for an object that does not exist seems like an exceptional case to me. Coupled with a method that allows a caller to determine if an object exists, I think it would be ok to throw the exception when it doesn't.

public bool exists( String key ) { ... }

Caller could do:

if (exists(key)) {
   CustomObject modified = get(key,DateTime.Today.AddDays(-1));
   if (modified != null) { ... }
}

or

try {
    CustomObject modified = get(key,DateTime.Today.AddDays(-1));
}
catch (NotFoundException) { ... }

Answer 3

The problem with exceptions is they are meant to signal a "fail fast" scenario (i.e. if not processed, an exception will stop an application) due to an exceptional and abnormal behavior.

I do not think that "the scenario where the key exists but the object has not been modified" is an exceptional one, certainly not an abnormal one.

Hence I would not use exception, but rather I would document the action the caller need to do in order to correctly interpret the result (property or special object).

Answer 4

It sounds like you actually want to return two items: the response code and the object found. You might consider creating a lightweight wrapper that holds both and return them together.

public class Pair<K,V>{
  public K first;
  public V second;
}

Then you can create a new Pair that holds your response code and the data. As a side effect to using generics, you can then reuse this wrapper for whatever pair you actually need.

Also, if the data hasn't expired, you could still return it, but give it a 303 code to let them know that it is unchanged. 4xx series would be paired with null.

Answer 5

You can create a special final CustomObject as a "marker" to indicate unchanged:

static public final CustomObject UNCHANGED=new CustomObject();

and test for a match with "==" instead of .equals().

It might also work to return null on unchanged and throw an exception on does not exist? If I had to choose one of your 3, I would choose 1 because that seems the most exceptional case.

Answer 6

I'd still return null.

The intention of the property is to return the object that was modified after the specified date. If returning null for no object is ok, then surely returning null for an unmodified object is ok too.

I personally would return null for a non-modified object, and throw an exception for a non-existing object. That seems more natural.

You're quite right to not use exceptions for flow control BTW, so if you only have those 3 options, your gut instinct is right.