C++ Exception Performance: Zero-Cost, noexcept, and Error Codes
이 글의 핵심
How C++ exceptions behave at runtime: happy-path cost, expensive throw path, choosing exceptions vs error codes, and noexcept interaction with containers.
Introduction
C++ uses a zero-cost exception model on the success path: when no exception is thrown, cost is usually tiny. When an exception is thrown, stack unwinding is expensive. This article surveys behavior and tuning.
1. Zero-cost exception model
Success path vs throw path
#include <iostream>
#include <chrono>
void normalPath() {
try {
int x = 42;
int y = x * 2;
} catch (...) {
}
}
void exceptionPath() {
try {
throw std::runtime_error("error");
} catch (...) {
}
}
Typical measurements show the throw path orders of magnitude slower per iteration than straight-line code—benchmarks depend on compiler, OS, and depth.
Idea behind “zero-cost”
// Compiler / runtime model (simplified):
// 1. Success path: minimal extra code on hot path
// 2. Exception tables: metadata elsewhere
// 3. On throw: table lookup + unwind + dtors
2. Cost breakdown
What a throw does
class Resource {
public:
Resource() { std::cout << "ctor" << std::endl; }
~Resource() { std::cout << "dtor" << std::endl; }
};
void func3() {
Resource r3;
throw std::runtime_error("error");
}
void func2() {
Resource r2;
func3();
}
void func1() {
Resource r1;
func2();
}
int main() {
try {
func1();
} catch (const std::exception& e) {
std::cout << "caught: " << e.what() << std::endl;
}
}
Costs include exception object construction, table lookup, unwinding frames, and calling destructors along the way.
Deeper stacks cost more
Throwing through many frames is slower than shallow throws—keep error handling high-level when possible.
3. Error codes vs exceptions
Shape of APIs
#include <optional>
std::optional<int> divideErrorCode(int a, int b) {
if (b == 0) {
return std::nullopt;
}
return a / b;
}
int divideException(int a, int b) {
if (b == 0) {
throw std::invalid_argument("divide by zero");
}
return a / b;
}
On the success path, well-optimized code with or without try can be similar; on the error path, exceptions are usually far more expensive than returning nullopt or a sentinel.
4. noexcept optimization
noexcept and containers
class Widget {
int* data;
public:
Widget() : data(new int(42)) {}
// Potentially-throwing move: vector may copy on growth
Widget(Widget&& other) {
data = other.data;
other.data = nullptr;
}
// noexcept move: vector can move elements
Widget(Widget&& other) noexcept {
data = other.data;
other.data = nullptr;
}
~Widget() { delete data; }
};
5. Common pitfalls
Pitfall 1: Exceptions for control flow
Prefer normal branches (if, break, return) over throw for frequent control transfer.
Pitfall 2: Frequent throws
Parsing or validation in a tight loop should usually return optional, expected, or error codes—not throw on every bad token.
Pitfall 3: Huge exception objects
Keep exception types small; avoid embedding giant buffers in the exception object.
Pitfall 4: -fno-exceptions
Embedded or extreme environments may disable exceptions entirely—use optional, expected, or error codes consistently.
6. Optimization strategies
Use noexcept where true
class Buffer {
std::vector<int> data;
public:
Buffer(Buffer&& other) noexcept
: data(std::move(other.data)) {}
void swap(Buffer& other) noexcept {
data.swap(other.data);
}
~Buffer() noexcept = default;
};
Minimize throws
Reserve exceptions for exceptional paths (I/O open failure, invariant violation). Use error codes for expected failures (bad user input line).
Document contracts
Mark noexcept on functions that truly cannot throw; use conditional noexcept in templates.
7. Example: file processing
#include <fstream>
#include <string>
#include <optional>
#include <vector>
#include <iostream>
class FileProcessor {
public:
std::vector<std::string> readLines(const std::string& filename) {
std::ifstream file(filename);
if (!file) {
throw std::runtime_error("open failed: " + filename);
}
std::vector<std::string> lines;
std::string line;
while (std::getline(file, line)) {
lines.push_back(line);
}
return lines;
}
std::optional<int> parseLine(const std::string& line) noexcept {
try {
return std::stoi(line);
} catch (...) {
return std::nullopt;
}
}
std::vector<int> processFile(const std::string& filename) {
auto lines = readLines(filename);
std::vector<int> numbers;
for (const auto& line : lines) {
if (auto num = parseLine(line)) {
numbers.push_back(*num);
}
}
return numbers;
}
};
Summary
Key points
- Zero-cost: cheap success path in typical implementations
- Throw cost: unwind + dtors—expensive
- noexcept: enables optimizations and better container behavior
- Error codes: better for frequent, expected failures
- Exceptions: better for rare, hard failures
Exceptions vs error codes
| Situation | Typical choice | Reason |
|---|---|---|
| File missing | Exception | Rare in steady state |
| Network down | Exception / typed error | Often rare |
| Parse failure per line | Error code / optional | May be frequent |
| Input validation | Error code | Frequent |
| OOM (operator new) | Exception (unless no-except build) | Rare, severe |
| Out-of-range programmer bug | Exception / assert | Not a hot path |
Practical principles
- Do not use exceptions for ordinary control flow
- Prefer error codes where failures are common
- Mark
noexceptwhen accurate - Keep destructors non-throwing
- Profile real workloads
Related posts
- noexcept
- Exception safety
- Cache optimization
- Profiling
- Algorithm sort
- Benchmarking