Well said. This feels terrible: just silently ignore logical errors (where some code expects but doesn't receive a fully constructed object) and ... keep going.

Well said. This feels terrible: just silently ignore logical errors (where some code expects but doesn't receive a fully constructed object) and ... keep going. I'd rather take a crash (that way I'll know soon that I have a bug and it'll be easy to fix) or, even better, a compiler/type error ("code is expecting a fully constructed object but doesn't always receive one"). In C++ I recently started using a NonNull<> templated type (with specializations for std::unique_ptr<> and std::shared_ptr<>): https://github.com/alefore/edge/blob/af1192a70646f662539bfe6b2be154508ef0dc8e/src/language/safe_types.h#L66 https://github.com/alefore/edge/blob/af1192a70646f662539bfe6... It's slightly verbose, but has allowed me to delete a ton of CHECK(x != nullptr) statements (since the type will already carry the information that x can't be null) and this use of types has helped me detect a few mismatches (where e.g. the consumer had unnecessary complexity to deal with null but the caller always emitted fully constructed types, or the, much worse, symmetric case).