This is effectively a one to one mapping to Redis commands. Depending on the implementation either the redis response and/or redis write are asynchronous. Regardless, each method returns an extension of {@link Future} and the returned results conforms to the contract of that interface (whichyou should review).
If your request results in a {@link RedisException}, the call to {@link Future#get()} (of either flavor)will raise a {@link ExecutionException} with {@link ExecutionException#getCause()} returning the underlying{@link RedisException}.
Similarly, if the request results in either {@link ClientRuntimeException} or {@link ProviderException}, the {@link Future}'s {@link ExecutionException} will wrap these as the cause.
Beyond that , just be aware that an implementation may throw {@link ClientRuntimeException}or an extension to report problems (typically connectivity) or {@link ProviderException}(to highlight implementation features/bugs). These are {@link RuntimeException} that have been encountered while trying to queue your request.
Note that this interface provides no guarantees whatsoever regarding the execution of your requests beyond the strict ordering of the requests per your invocations. Specifically, in the event of connection issues, this interface's contract does not place any requirements on the implementation beyond to notify the user of such issues either during a call to this interface, or, on the attempt to get the result of a pending response on {@link Future#get()}. Refer to the documentation of the implementation of {@link JRedisFuture} for the specifics of behavior in context oferrors. @author Joubin (alphazero@sensesay.net) @version alpha.0, 04/02/09 @since alpha.0
| |
| |