15.9 Exception-Handling Requirements [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 15.9 Exception-Handling Requirements ======

[[fxdemo:04-part:15-phase-0-developer-handbook-requirements:start | Go To Phase 0 Developer Handbook Requirements ]]

The Developer Handbook must define exception-handling patterns for Phase 0 implementation artifacts.

Exception-handling requirements must identify:

  - Processing boundaries where implementation [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Nodes]] capture exceptions
  - Required exception context
  - Node or participant identity
  - Correlation identifiers
  - Affected logical interaction where available
  - Affected [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Topic or generated type where available
  - Timestamp
  - Exception type or error category
  - Processing outcome
  - Retry or recovery expectation
  - Health-reporting effect
  - Audit/provenance effect
  - Control-plane effect where applicable

Operational exceptions must support Health and Observability when they describe node condition, degradation, failure, warning, or recovery. Exceptions that affect logical processing, lineage, replay, reconstruction, release, or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] must support Audit and Provenance. Exceptions that require retry, pause, resume, restart, or recovery coordination must support Control Plane interaction.

Exception handling must not hide processing failures. An implementation artifact must either handle the exception according to the approved pattern or report the failure through the appropriate logging, status, audit/provenance, or control mechanism.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>