Throwing Exceptions in C++

Every function is written to do a job. Sometimes the job cannot be completed. The input may be invalid, a required resource may be missing, or a calculation may be meaningless. Good error handling is the discipline of deciding, in advance, how a program will respond in those moments.

This article covers three practices: throwing an exception when a task cannot be performed, developing an error-handling strategy early in the design, and declaring a function noexcept when it is not meant to throw. The main worked idea is a Vector whose subscript operator must refuse requests for positions that do not hold an element.

The key question is when a throw is appropriate. The source's guidance is to throw an exception to indicate that you cannot perform an assigned task. The trigger is therefore not that something looks unusual. The trigger is that the function genuinely cannot carry out what it was asked to do.

Consider a function that divides two numbers. If the divisor is zero, the function has no sensible result to return. Throwing is the way the function says that the task cannot be completed. It does not invent a fake answer that the caller might mistake for a real one.

The source recommends developing an error-handling strategy early in a design. Error handling should not be an afterthought added once the rest of the program is written. When the design is still forming, the team decides which operations can fail, which failures mean the task cannot be performed, and how those failures will be signaled to the rest of the program.

This timing matters because the choice affects every function that depends on the class. If the Vector class has already been written with no agreed way to report failure, each later function has to invent its own response. Deciding the signaling method first gives every function one consistent channel.

The noexcept keyword appears after the parameter list in a function declaration. It is a statement of intent: this function is designed not to throw exceptions. The contrast the source draws is between functions that may not throw, which should be declared noexcept, and functions that may throw, which are not declared that way.

Declaring noexcept therefore tells readers of the code something about the function's behavior before they read its body. A caller who sees the keyword knows the function is not expected to report failure by throwing. A caller who sees no keyword must assume that a throw is possible.

Every container has a rule about which positions are legal. A Vector holds a fixed number of elements, and its subscript operator lets a program pick one of them by index. Asking for an index that does not correspond to a stored element is an error in the program that made the request.

The source states the design goal directly. The person who writes the Vector implementation is responsible for detecting an attempted out-of-range access. Detection alone is not enough. The implementer must then tell the user about the problem, and the user decides what action to take. The error is surfaced so that the code that caused it, or the code that calls it, can respond.

This separates two jobs. The Vector knows the valid range, because it knows its own size. The user knows what the program should do next. Throwing an exception is the channel through which the Vector hands the problem to the user without deciding on the user's behalf.

A valid index names a stored element. If the Vector holds n elements, the valid indices run from 0 up to n minus 1, which can be written as $0 \leq i < n$. Any index below zero or at or above n is outside the range. The guard in the Vector's subscript operator is built around exactly this boundary.

Read the strip from left to right. Indices in the middle of the strip are accepted and return an element. The index just below zero and the index equal to n both fall outside the range and both throw. The same boundary test covers both ends of the range.

The guard in Vector's subscript operator tests the index before any element is accessed. It checks whether i is less than 0, or whether size() is less than or equal to i. A failing guard causes an out_of_range exception to be thrown. A passing guard returns a reference to the element.

Every call enters the function at the same point and must pass the guard. Only one of the two outgoing paths is taken for a given index. The throw path is the only one that ends in an exception rather than a returned element. Watching the guard decide which branch runs is the moment where the behavior of a valid request and a rejected request separates.

The flowchart below shows the guard as a single decision with two outgoing paths. Every call starts at the top. The guard either lets control continue to the return statement, or sends control to the throw. The decision is made before any element is touched, so an invalid position never reaches the storage.

Read the diagram as a fork. The guard is the only decision point. The yes branch ends in the throw, and the no branch ends in returning the element. The guard tests two separate conditions, and the first one covers indices below the valid range, so a negative index is rejected before the second test matters.