Java – how to avoid using exception flow control?

I was assigned a project to develop a set of classes that act as interfaces to storage systems One requirement is that the class supports get methods with the following signatures:

public CustomObject get(String key,Date ifModifiedSince)

Basically, if and only if the object is modified after ifmodifiedsince, the method should return the customobject associated with the keyword If the storage system does not contain a key, the method should return null

My question is:

How to handle the case where the key exists but the object has not been modified?

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

The solution I'm measuring is:

>Throw a custom exception the storage system does not contain keys > throw a custom exception ifmodifiedsince failed. > Add properties to customobject Ask the caller to inspect the property

I am not satisfied with all three options I don't like options 1 and 2 because I don't like using exception flow control I also don't like returning values when my intention is to express no value

However, I prefer 3

Is there a choice I don't consider? Does anyone have a strong feeling about these three options?

The answer to this question, interpretation:

>Provide an include method and ask the caller to call it. When calling get (key, ifmodifiedsince), throw exception. If the key does not exist, if the object has not returned null modification Wrap the response and data (if any) in the composite object. > Use predefined constants to represent some states (unmodified, key_does_not_exist). > The caller implementation interface is used as a callback. > The design is terrible

Why can't I choose the answer #1

I agree that this is the ideal solution, but I have been (reluctantly) dismissed The problem with this approach is that in most cases where these classes are used, the back-end storage system will be a third-party remote system, such as Amazon S3 This means that the included method will require a round trip to the storage system, which in most cases should be another round trip Because it will cost time and money, it is not an option

If it were not for this limitation, this would be the best way

(I realize that I didn't mention the important factors of this issue, but I'm trying to keep it brief, which is obviously relevant.)

Conclusion:

After reading all the answers, I come to the conclusion that packaging is the best way in this case In essence, I will imitate HTTP, including metadata (title), response code and content body (message)

Solution

It sounds like you really want to return two items: the response code and the found object You might consider creating a lightweight wrapper that can either save them at the same time or return them

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

You can then create a new pair that holds your response code and data As a side effect of using generics, you can use this wrapper again to implement any pair you need

In addition, if the data is not expired, you can still return it, but give it a 303 code to let them know that it has not changed 4xx series will pair with null