WG013 — Catching Throwable or Error in workflow code

[vikas0686]

Category: Determinism, extended
Priority: P0
Severity: ERROR

Problem

Workflow code contains catch (Throwable t) or catch (Error e).

Why it breaks Temporal

The SDK uses unchecked Error subclasses internally as control-flow signals — for cancellation, for the destroy path when a workflow task fails deterministically. Swallowing them breaks that internal control flow: a cancellation can silently fail to propagate, or a workflow task that should safely fail-and-retry instead limps forward in a corrupted state.

Example (violating code)

try {
  activities.chargeCard(order);
} catch (Throwable t) {
  logger.warn("ignoring", t); // swallows Temporal's internal Error signals too
}

Recommended fix

Catch specific checked/application exceptions (ActivityFailure, your own business exceptions) — never Throwable or Error directly.

Detection strategy

AST — flag any catch clause whose type is Throwable or Error (or a superclass of a known Temporal internal Error) inside a workflow implementation.

False positive considerations

Very low — there is no legitimate reason to catch bare Error in workflow code.

Estimated implementation complexity

Low — pure AST pattern, no traversal needed.

---

Proposed rule from WoGu's post-determinism rule-roadmap brainstorm. Not yet implemented — priority, severity, and complexity are starting estimates for scoping, not a committed spec.