Runtime & concurrency
Reveal answer and reasoning
Use static initialization for small deterministic type state whose one-time lifetime and failure semantics fit the design. If startup requires external acquisition, retries, cancellation, disposal, or meaningful recovery, an explicit owned operation often exposes those responsibilities more clearly. Avoid blocking a static initializer on work that may need the same type to initialize, and distinguish per-type state from process-wide or deployment-wide authority.
Test the intended first-use path and any separate closed generic type state deliberately, without requiring incidental beforefieldinit timing. For an explicit startup service, test failure, cancellation, retry policy, and cleanup as ordinary owned outcomes. The wrong design hides a long network-dependent initialization behind a static field and assumes calling the type again is a reliable recovery loop. A deterministic print sequence can confirm one initialization boundary, but it cannot establish robust startup behavior for external resources that the initializer never safely owns or releases.
What a strong answer covers
- Choose a lifetime and failure model deliberately.
- Avoid blocking cyclic initialization dependencies.
- Use explicit owned startup for recovery and external resources.
Common pitfall
Hiding recoverable resource acquisition inside a one-time static initializer.
Follow-up questions
- How would you dispose a resource created at startup?
- How would separate generic constructions affect static state?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.