Constructors Shouldn't Throw

It argues that constructors should never throw exceptions, perform asynchronous work, or cause side effects; they should only put objects into a simple, valid state. Practical recommendations include moving parsing and I/O out of constructors: implement a Date.parse(string) that uses a parser and calls a private constructor, make a Database type a state machine with an uninitialized state and an explicit connect() method (which unit tests will appreciate), and perform API requests in factory functions that pass resolved data into constructors. Minor side effects like logging are tolerated, but anything that can fail or has latency belongs outside the constructor.

The rationale draws on both C++ practice and general design principles: in C++ noexcept default constructors avoid half-constructed objects, resource leaks, and complicated cleanup during container operations, and similar predictability is desirable in other languages. Keeping construction simple enforces separation of concerns, makes object lifecycles explicit, and prevents surprising failures where objects are created in different places than they’re used. When objects require complex setup, the API should expose explicit lifecycle transitions or factory methods rather than hiding work in constructors.