-
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.
-
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) { ... }
-
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.
-
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).
-
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.
-
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 , Date modifSince );
if( 0 == null ) {
setResponseCode( 302 );
} else {
setResponceCode( 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 , Date modif );
if( o != null ) {
setResponseCode( 200 );
pus( o );
} else {
setResponseCode( 404 ); // ether 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.
-
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.
-
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
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.
-
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.
-
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.
-
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.
