A courts e-filing notifier starts cleanly, then crashes when the API returns an unexpected null for a docket field. How does this differ from a syntax failure?

A courts e-filing notifier that starts cleanly and then crashes when the API returns an unexpected null for a docket field is a runtime exception. Syntax analysis already succeeded; the program entered execution, performed I/O, and only then hit invalid assumptions about the response shape. Defensive coding—null checks, schema validation, and explicit handling of missing docket fields—belongs in the runtime path.

Calling this a syntax error because “null is invalid in every programming language” confuses language grammar with data validity. Null may be a legal value in JSON while still being unacceptable for a required business field; that is application logic, not parse failure of the source file. Proving the Git remote is unreachable is unrelated: the notifier started and contacted the API. A deleted Dockerfile base image tag would typically break build or pull, not produce a mid-run null dereference after a successful start.

Exam caveat: stack traces can mention “parse” when parsing API payloads fails; that is still runtime relative to the script’s own source. Exam questions that emphasize “starts cleanly, then crashes” are steering you to runtime versus syntax. Multi-select or scenario stems may also mix Git and container distractors—tie the failure to when it occurs in the life cycle.

Operational check: reproduce with a fixture payload that omits the docket field, confirm the process starts and fails at the response-handling line, add validation or a safe default per courts policy, and verify metrics/logs show the API call succeeded while the handler no longer crashes on null.