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 following signature:

public CustomObject get(String key, Date ifModifiedSince)

Basically the method is supposed to return the CustomObject associated with the key if and only if the object has been modified after ifModifiedSince. If the storage system does not contain the key then the method should return null.

My problem is this:

How do I handle the scenario where the key exists but the object has not been modified?

This is important because some applications that use this class will be web services and web applications. Those applications will need to know whether to return a 404 (not found), 304 (not modified), or 200 (OK, here's the data).

The solutions I'm weighing are:

1. Throw a custom exception when the storage system does not contain the key
2. Throw a custom exception when the ifModifiedSince fails.
3. Add a status property to the CustomObject. Require caller to check property.

I'm not happy with any of these three options. I don't like options 1 and 2 because I don't like using exceptions for flow control. Neither do I like returning a value when my intent is to indicate that there was no value.

Nonetheless, I am leaning towards option 3.

Is there an option I'm not considering? Does anyone have strong feelings about any of these three options?

---

Answers to this Question, Paraphrased:

1. Provide a contains method and require caller to call it before calling get(key, ifModifiedSince), throw exception if key does not exist, return null if object has not been modified.
2. Wrap the response and data (if any) in a composite object.
3. Use a predefined constant to denote some state (UNMODIFIED, KEY_DOES_NOT_EXIST).
4. Caller implements interface to be used as callbacks.
5. The design sucks.

---

Why I Cannot Choose Answer #1

I agree that this is the ideal solution, but it was one I have already (reluctantly) dismissed. The problem with this approach is that in a majority of the cases in which these classes will be used, the backend storage system will be a third party remote system, like Amazon S3. This means that a contains method would require a round trip to the storage system, which would in most cases be followed by another round trip. Because this would cost both time and money, it is not an option.

If not for that limitation, this would be the best approach.

(I realize I didn't mention this important element in the question, but I was trying to keep it brief. Obviously it was relevant.)

---

Conclusion:

After reading all of the answers I have come to the conclusion that a wrapper is the best approach in this case. Essentially I'll mimic HTTP, with meta data (headers) including a response code, and content body (message).

Answer 1

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 2

With the given requirement you cannot do this.

If you designed the contract, then add a condition and make the caller invoke

exists(key): bool

The service implementation look like this:

if (exists(key)) {
    CustomObject o = get(key, ifModifiedSince);
    if (o == null) { 
      setResponseCode(302);
    } else {
      setResponseCode(200);
      push(o);
   }

} else {
      setResponseCode(400);
}

The client remains unchanged and never notice you've validated upfront.

If you didn't design the contract Probably there's a good reason for that or probably it's only the designer (or architect) fault. But since you cannot change it, then you don't have to worry either.

Then you should adhere to the specifications and proceed like this:

 CustomObject o = get(key, ifModifiedSince);

 if (o != null) {
     setResponseCode(200);
     push(o);
  } else {
     setResponseCode(404); // either not found or not modified.
  }

Ok, you're not sending 302 in this case, but probably that is the way it was designed.

I mean, for security reasons, the server should not return more information than that [ the probe is get( key, date ) only return either null or object ]

So don't worry about it. Talk with your manager and let him know this decision. Comment the code with this decision too. And if you have the architect in hand confirm the rationale behind this strange restriction.

Chances are they you didn't see this coming and they can modify the contract after your suggestion.

Sometimes while wanting to proceed right we may proceed wrong and compromise the security of our app.

Communicate with your team.

Answer 3

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 4

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 5

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 6

How strict is the requirement for that method signature?

It seems as though you are working on a project that is still in progress. If the consumers of your class are other developers, can you convince them that the method signature they have asked for is insufficient? Perhaps they haven't yet realized that there should be two unique failure modes (key does not exist and object has not been modified).

I would discuss it with your supervisor if that is an option.

Answer 7

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.

Answer 8

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 9

The (intended) interface regarding the requirements is seriously broken. You try to do unrelated things within one method. This is the road to software hell.

Answer 10

Provide a Callback as the argument where the Callback class could either be event driven, or setter driven.

You have your class's interface define the various errors that can occur, passing in the CustomObject as the parameter for the event, if needed.

public interface Callback {
  public void keyDoesNotExist();
  public void notModified(CustomObject c);
  public void isNewlyModified(CustomObject c);
  .
  .
  .
}

In this way, you allow the implementor of the Callback interface to define what to do when the event occurs, and you can choose through the interface, whether that conditions requires the passing of the retrieved object. Lastly, it reduces the complexity of the logic on a return. Your method does that once. Implementors of the API don't require doing it at all, as it's done for them.

Answer 11

If it is acceptable, you may return an amplified CustomObject (a wrapper), which contained values which represented the object and its modification state, if any, etc.