====== 10.9 Node Error Handling ======

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

[[fxdemo:05-part:10-node-implementation-pattern:start | Return to Node Implementation Pattern ]]

A [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] should handle errors in a predictable and observable way. Error handling should distinguish Configuration errors, [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] communication errors, type-generation or binding errors, runtime dependency errors, command-handling errors, data-processing errors, and shutdown errors.

A Node should:

  - Log errors with enough context to support diagnosis.
  - Avoid exposing secrets or sensitive local values.
  - Publish ''Degraded'', ''Recovering'', or ''Failed'' status when the error affects Node operation.
  - Reject invalid commands or messages clearly.
  - Use meaningful exit codes when the process exits.
  - Preserve [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] needed for testing and review.
  - Avoid swallowing exceptions without logging or status impact.
  - Avoid uncontrolled retry loops.

Recoverable errors may allow the Node to continue in the ''Degraded'' or ''Recovering'' state. Non-recoverable errors should move the Node toward a failed or controlled shutdown. The Node profile should define any Node-specific recovery behavior.

Exception handling code shall follow the file header and inline documentation conventions defined in Section 7.10. Functions or methods that raise, catch, translate, log, suppress, or propagate errors shall document the relevant error conditions and expected recovery or failure behavior.

----

<WRAP centeralign>

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

</WRAP>