# io.github.libtmux.Pane.Pane.dead

- **Module:** io.github.libtmux.Pane.Pane
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-java/blob/842228310449e879ebcaa3f910597757c9dbffd6/libtmux/src/main/java/io/github/libtmux/Pane.java#L187
- **Page:** https://libtmux.org/en/java/latest/reference/io-github-libtmux-pane-pane-dead/

```
io.github.libtmux.Pane.Pane.dead() -> boolean
```

Whether this pane's process has exited, read fresh rather than from the capture.

Dying is something that happens between reads, so a cached answer would report a pane that
died after this handle was captured as alive forever — the trap a snapshot-backed {@code
isDead()} would set, which is why there is no such accessor on the capture itself. This asks
tmux directly instead, every time.

A dead pane is not necessarily a gone one: {@code remain-on-exit} keeps it around, still
listed, to be read. A pane with no {@code remain-on-exit} is simply removed once its process
exits — {@link #refresh()} on this handle then throws {@link ObjectDoesNotExistException}, and
this method throws too. Unlike every other command {@code Pane} sends, {@code display-message
-t} does not error on a target it cannot resolve — it exits 0 with nothing on stdout — so a
gone pane looks like a live one that answered nothing rather than like a failure. That empty
read, and not a "can't find pane" from tmux, is what this method throws on: a real pane always
answers {@code 0} or {@code 1} for this format, never nothing.

## Raises

- `ObjectDoesNotExistException`: if the pane is gone from a server that still answers