====== 16.6 Container Errors ======

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

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

Containers should remain visible to developers, testers, reviewers, and demonstration operators. Container startup, runtime, networking, logging, and shutdown failures should not disappear inside the container runtime.

Container error handling should identify:

  - Image build failure.
  - Missing build inputs.
  - Missing generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]].
  - Invalid runtime [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]].
  - Missing mounted files or volumes.
  - Container networking failure.
  - [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] discovery failure inside the container environment.
  - Process startup failure.
  - Process termination or crash.
  - Log export failure.
  - Controlled shutdown failure.
  - Cleanup failure.

The build and run scripts should report container errors clearly. Container logs should preserve [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] or service errors where practical. If a container fails to start a required Node, the run script should report failure and return a non-zero exit code.

Container cleanup should not delete logs or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] needed to diagnose a failure unless the user explicitly requests destructive cleanup.

----

<WRAP centeralign>

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

</WRAP>