====== 16.2 Node Exceptions ======

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

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

Nodes should handle exceptions in a way that preserves runtime visibility and Lifecycle discipline. A Node should not crash silently, continue after a critical failure, or report Running when it cannot perform its required Phase 0 role.

Node exception handling should identify:

  - Configuration errors.
  - Startup errors.
  - DDS participant initialization errors.
  - Publisher or subscriber creation errors.
  - Generated type or binding errors.
  - Topic publication or subscription errors.
  - Command-handling errors.
  - Data-processing errors, where applicable.
  - Logging failures.
  - Shutdown errors.
  - Unexpected runtime exceptions.

When a Node detects an exception, it should log the error with relevant context. Where possible, it should publish an appropriate [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status such as Degraded, Recovering, or Failed. If the Node cannot continue safely, it should move toward controlled shutdown and exit with a meaningful exit code.

A Node may continue running after a recoverable error if the Node profile defines the recovery behavior. For example, a Node may reject an invalid command, log the rejection, publish current status, and continue Running. A Node should not continue Running after a failure that prevents required startup, DDS participation, status reporting, or safe shutdown.

----

<WRAP centeralign>

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

</WRAP>