# Errors and exceptions

Source: https://libtmux.org/en/rs/latest/topics/errors-and-exceptions/

> Handle command failures, inspect delivery status, and decide when a retry is safe.

A command can fail because tmux rejects it, or because the transport stops
before returning a reply. Inspect the reported error and delivery state before
retrying a mutation: tmux may already have received it.

For lookup failures caused by zero or multiple matches, see [Filtering and
queries](https://libtmux.org/en/rs/latest/concepts/queries/#the-cardinality-contract-side-by-side).

## A failed command, as a value

Fallible operations return `Result<T, Error>`. Match the
non-exhaustive [`Error`](<https://libtmux.org/en/rs/latest/reference/error-error/>) enum and include a fallback for variants added later.

## Is it safe to retry?

Retry a mutation automatically only when you know it was not dispatched, or when
repeating it is safe for your operation. A timeout, cancellation, or dropped
connection can occur after tmux has acted. These APIs expose delivery
information:

With the `control-mode` feature, [`ControlModeErrorKind.DispatchTimedOut`](<https://libtmux.org/en/rs/latest/reference/error-controlmodeerrorkind-dispatchtimedout/>)
means the command was not dispatched. A plain timeout can occur after tmux
received the command, so do not infer that retrying is safe.

Treat unknown delivery as potentially executed.

[`DispatchTimedOut`](<https://libtmux.org/en/rs/latest/reference/error-controlmodeerrorkind-dispatchtimedout/>) identifies a request that did not reach tmux.

For subprocess calls that complete normally, inspect the exit status. If a call
is interrupted or times out without a delivery state, check tmux's resulting
state before repeating a mutation.