Official information may be found at the Java Client Library page.
The Java client library has a set of synchronous and asynchronous methods. While it doesn't happen in most situations, occasionally network IO can become congested, nodes can fail, or memory pressure can lead to situations where an operation can timeout.
When this timeout occurs, most of the synchronous methods on the client will return a RuntimeException showing a timeout as the root cause. Since the asynchronous operations give finer grained control over how long is given for an operation to be successful or unsuccessful, this path throws a checked TimeoutException.
As an application developer, it's best to think about what you would do after this timeout. This may be something like showing the end user a message, it may be nothing, or it may be going to some other system for additional data.
In some cases, it may make sense to retry the operation, but this should be thought about carefully, as the cause of the timeout may be exacerbated. In the case of deciding to retry, doing this with a backoff or exponential backoff (see bulk loading below for an example) is advisable. This can be conceptually thought of as a pressure relief valve for intermittent resource contention.
When doing bulk loading of Couchbase Server, one can frequently overwhelm available memory in the Couchbase cluster before it can store data on disk. When this happens, Couchbase Server will immediately send a response back indicating the operation cannot be handled at the moment, but likely can be handled later. This is sometimes referred to as "handling Temp OOM" (where OOM means out of memory), though the actual temporary failure could be sent back for reasons other than OOM. Temporary OOM is the most common, however.
There are plans for future client support to handle this automatically, but handling it in your application is really a matter of a simple do-while.
One example of performing bulk loading when receiving temporary failures is: