16.8 Error Reporting

Go To Top

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:

1. Component or script name.
2. Node Identity, where applicable.
3. Operation being attempted.
4. Configuration source, where relevant.
5. Topic or type name, where relevant.
6. Tool or product name, where relevant.
7. Version information, where relevant.
8. Error code, exception class, or failure category.
9. Human-readable error message.
10. Suggested next inspection point.
11. 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 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.