Error Handling

Error Handling

client-go may return some specific types of errors when executing commands, which usually need to be saved or exported by higher-level applications.

We use the pkg/errors library to define errors. Usually an error contains information of the call stack. Also an error may be formed as a error chain of several different types of errors. pkg/errors defines a variety of ways to check or format errors. You can refer to its documentation for more details.

Errors are also compatible with errors.Is and errors.As methods from the standard library (thanks to pkg/errors).

Almost all of the predefined errors can be found in the error/error.go file. If you need to check for a specific error, use errors.Is for errors that defined as variables and errors.As for errors that defined as types.

There are several errors that you may want to handle them specifically depending on the situation rather than just throwing them to upper level:

1. ErrNotExist

When reading a key-value, if it is possible that this key-value does not exist, you will need to check the returned error specially.

2. ErrWriteConflict or ErrWriteConflictInLatch

The presence of these two errors means that the optimistic transaction is conflicting with other concurrent transactions during the commit process. Generally a retry on the application side is needed. If these errors occur too often, consider switching to pessimistic transactions.

3. ErrDeadLock

Similar to write conflicts but appears when use pessimistic transactions. Generally a retry on the application side is needed.

4. ErrRetryable

There are many errors that could be resolved by retry the transaction again, such as ErrWriteConflict and ErrDeadLock mentioned above. ErrRetryable is a handy type the determine if it is fessible to retry.

5. ErrResultUndetermined.

It is a very special kind of error. It usually occurs when a transaction commit encounters an error and is unable to connect to target server despite mulitple retries. In this case, client-go itself cannot determine whether the transaction will commit or rollback. It requires the application layer to query again to determine the status of the transaction after service is restored.