# `try_catch` — Fehlergrenze mit Retry-Policy

**Zweck:** Umschließt beliebige Tasks: Wirft einer davon einen Fehler (`TaskResult error` oder PHP-Exception), bricht nicht mehr der ganze Workflow ab. Stattdessen wird — nach optionalen automatischen Wiederholungen mit Backoff — der `<catch>`-Zweig ausgeführt (z. B. Admin-Mail, Ersatzwert setzen) und der Workflow läuft weiter. Retries nutzen `resume_at` + `cron-resume`.

**Parameter**

| Name | Pflicht? | Default | Beschreibung |
|---|---|---|---|
| `try`/`task` | **ja** | — | Zu überwachende Tasks (wie eine Sequenz) |
| `retry` (`max`) | nein | `0` | Anzahl automatischer Wiederholungen nach einem Fehler |
| `retry` (`backoff`) | nein | `60` | Wartezeiten in Sekunden je Versuch (CSV); letzter Wert gilt für weitere |
| `catch`/`task` | nein | — | Tasks nach erschöpften Retries; ohne `<catch>` wird der Fehler durchgereicht |

**Eingangswerte:** Kontext der umschlossenen Tasks. Im `<catch>`-Zweig zusätzlich verfügbar:
- `<task_id>_fehler` — Fehlermeldung des letzten Versuchs
- `<task_id>_versuche` — Anzahl der Versuche

**Ausgangswerte:** Die Ausgaben der ausgeführten `<try>`- bzw. `<catch>`-Tasks landen im Kontext. Ohne `<catch>` endet der Task nach erschöpften Retries mit Fehler.

**XML-Beispiel**

```xml
<task type="try_catch" id="hkr_sicher">
  <try>
    <task type="webhook" id="an_hkr">…</task>
  </try>
  <retry max="3" backoff="60,300,3600"/>
  <catch>
    <task type="email" id="admin_info">…</task>
    <task type="set_var" id="fallback"><var name="hkr_status">manuell</var></task>
  </catch>
</task>
```

**Hinweis:** Bei einem Retry wird nur der fehlgeschlagene Kind-Task zurückgesetzt; der Task geht in `waiting` und plant den Neuversuch über `resume_at`. `waiting`/`stop`/`return` der Kind-Tasks werden unverändert durchgereicht.