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

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 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

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 4

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 5

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.