====== 16.1 Purpose of Exception Handling Rules ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:16-exception-handling:start | Return to Exception Handling ]]

Exception handling rules help the team respond to errors consistently across [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Nodes]], scripts, containers, generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]], [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]], [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] communication, and validation workflows. A developer, tester, reviewer, or demonstration operator should be able to understand what failed, where it failed, why it mattered, and what the system did next.

Exception handling should support the following goals:

  - Detect errors close to their source.
  - Report errors with enough context to support diagnosis.
  - Avoid exposing secrets or sensitive local values.
  - Distinguish recoverable errors from non-recoverable errors.
  - Preserve logs and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]].
  - Publish appropriate [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status where possible.
  - Return meaningful exit codes where a process or script exits.
  - Avoid silently swallowing exceptions.
  - Avoid uncontrolled retry loops.
  - Keep failure behavior consistent with the Node [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] model.

Exception handling should not make Phase 0 appear more complete than it is. If a Node, script, generated Artifact, DDS participant, container, or validation step fails, the implementation should clearly report the failure.

----

<WRAP centeralign>

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

</WRAP>