====== 16.8 Error Reporting ======

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

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

Error reporting should provide enough information for a developer or reviewer to diagnose the problem without exposing secrets or sensitive local values.

An error report should include, where practical:

  - Component or script name.
  - [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] Identity, where applicable.
  - Operation being attempted.
  - [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] source, where relevant.
  - Topic or type name, where relevant.
  - Tool or product name, where relevant.
  - Version information, where relevant.
  - Error code, exception class, or failure category.
  - Human-readable error message.
  - Suggested next inspection point.
  - [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] or log location.

Error messages should use clear, active language. For example, “The script could not find the DDS generator at the configured path” gives more useful information than “DDS generation failed”.

Error reporting should align with the logging and observability conventions defined in Section 15. If the failure affects Node Lifecycle, the Node should also report the appropriate [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status where possible.

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>