# 0Z002 — stacked_diagnostics_accessed_without_active_handler

> Source-backed reference for PostgreSQL SQLSTATE 0Z002.
---

# 0Z002

## At a glance {#at-a-glance}

SQLSTATE 0Z002 is emitted by PL/pgSQL when code tries to use stacked exception state without the active exception handler that owns it. PostgreSQL 18.6 has two confirmed paths: `GET STACKED DIAGNOSTICS cannot be used outside an exception handler` and `RAISE without parameters cannot be used outside an exception handler`, both reported at ERROR level.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| Field | Value |
| --- | --- |
| SQLSTATE | `0Z002` |
| Condition | `stacked_diagnostics_accessed_without_active_handler` |
| Status | `active` |
| Known present by | `9.2.0` |
| Locked snapshots | `9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` |
| Macros | `ERRCODE_STACKED_DIAGNOSTICS_ACCESSED_WITHOUT_ACTIVE_HANDLER` |
| Aliases | `—` |

<!-- source facts: data/errcodes/0Z002.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#meaning}

The first path guards `GET STACKED DIAGNOSTICS`; the second guards a parameterless `RAISE` that would re-raise the current exception. The shared boundary is the PL/pgSQL `EXCEPTION` handler, not a SQL `BEGIN`/`COMMIT` transaction block. The SQLSTATE member is more specific than the 0Z000 category.

## Messages {#messages}

The fixed messages are `GET STACKED DIAGNOSTICS cannot be used outside an exception handler` and `RAISE without parameters cannot be used outside an exception handler`.

## Diagnosis {#diagnosis}

Locate the failing PL/pgSQL statement and the nearest `EXCEPTION` block. `GET STACKED DIAGNOSTICS` reads the exception being handled, while parameterless `RAISE` re-raises it; neither has stacked state outside a handler. Preserve the exact message and routine context because a transaction-state error or a new explicit `RAISE` has a different cause.

## Response {#response}

Move the diagnostic read or re-raise into the active exception handler, or use an explicit `RAISE` condition/message when no prior exception is being handled. Keep the handler narrow and preserve `RETURNED_SQLSTATE`, message, detail, and hint before leaving it. A code change, rather than a transaction retry, is the repair supported by this path.

## Versions {#versions}

The locked catalogue places this condition at least by PostgreSQL 9.2.0. The release definitions cover the published snapshots listed in the facts block; source-path status is limited to the fixed PostgreSQL 18.6 context cited below.

## Related {#related}

[`0Z000`](../0z000/), [`P0001`](../p0001/)

## Sources {#sources}

The fixed [PL/pgSQL executor source](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/pl/plpgsql/src/pl_exec.c#L2421-L2423) reports the GET STACKED DIAGNOSTICS variant, and [the RAISE path](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/pl/plpgsql/src/pl_exec.c#L3747-L3749) reports the parameterless variant. The [PL/pgSQL diagnostics documentation](https://www.postgresql.org/docs/18/plpgsql-control-structures.html#PLPGSQL-GET-DIAGNOSTICS) describes stacked fields. See the structured [evidence record](../data/evidence/0z002.json) for fixed source paths, scan scope, and unresolved runtime boundaries.