Constructors and Class Design in C++

Every function makes a promise to the code that calls it. Part of that promise is whether the function can fail by throwing an exception. Some functions can always complete normally. Others depend on input, memory, files, or other conditions that may not hold. In this article you will see how C++ lets a programmer state the first kind of promise directly in the function's declaration, how constructors use the idea of an invariant to decide whether an object should exist at all, and how static_assert moves certain checks out of run time and into compilation.

These three ideas belong together. The first two are connected by the concept of an invariant, which is a condition that an object must satisfy. The third gives you a tool for checking conditions that can be known before the program ever runs.

The decision belongs to the function's author, who knows what the function does internally. The rule to remember is short: when you can truthfully say a function may not throw, mark it noexcept. The keyword is a claim, and it should be made only when the claim is true.

The square function has nothing in its body that can fail, so the noexcept declaration is a truthful statement about it. This is the easy case. The harder question is what to do with a function that cannot promise it will succeed, which the constructor section addresses.

A function does not work alone. It is called by other code, which is called by still other code, and the chain of active calls is the call stack. The noexcept promise matters because callers rely on it when they decide what they can assume about a call. The diagram below shows a chain of calls where the innermost function is the one that might throw. Read it from top to bottom and ask which callers sit above the point of failure, and where a noexcept promise would stop a caller from having to plan for an exception.

In this chain, handle_request carries a noexcept promise, which tells its callers that they need not prepare for an exception leaving it. The constructor, by contrast, is allowed to fail, so it must not be declared noexcept. The author of each function decides which promise is true for that function, and the signatures make those decisions visible.

An invariant is a condition that an object must satisfy. A constructor's role is to establish that invariant. The source's rule is that the constructor should let the object's invariant become true, and it should throw if it cannot establish one. The constructor should not create an object that quietly breaks its own condition. If the arguments given to the constructor cannot make the invariant true, the constructor refuses to finish and signals the problem by throwing.

The flowchart shows the two outcomes. On the success path, the constructor finishes and the caller receives an object whose invariant holds. On the failure path, the constructor throws and the object never comes into existence. The failure path is deliberate. It prevents any part of the program from holding an object that claims to be valid while violating its own rules.

Consider the Percentage class from the source's example. Its job is to hold a value that is only meaningful between 0 and 100. That rule is the invariant. The code below is an illustrative version written to show how the constructor enforces the invariant and how the accessor, which cannot break the invariant, is declared noexcept.

The source advises that error-handling strategy should be designed around invariants. In practice, this means deciding where a program is allowed to be in a bad state and where it must not be. A class with a clear invariant gives its error handling a clear target: the object should never exist in a state that breaks its invariant. The constructor is the first place to enforce that rule, because it is where the object is created. Any function that changes the object must then keep the invariant true when it finishes.

The source does not list further error-handling patterns, so the guidance here is limited to that statement. Start by writing down the invariant for each class, then check that the constructor enforces it and that every mutating function preserves it. The Percentage example shows one application: the accessor is noexcept because reading the value cannot break the rule, while the constructor is where the rule is enforced.

static_assert is useful when the condition depends only on things known at compile time, such as the size of a type or a constant defined in the code. Moving such a check to compile time means it costs nothing at run time, and it cannot be skipped because an input happened to avoid the faulty path. The source advises using static_assert for checks that can be made at compile time, since checking there is preferable when it is possible.

The two kinds of check cover different parts of the same goal. A static_assert cannot examine a value that exists only when the program runs. The constructor check in the Percentage example depends on a value passed in during execution, so it must be a run-time throw. Compile-time checks handle what is fixed in the code, and run-time checks handle what arrives during execution.