In C++ exception handling, why can using exception objects be considered more expensive than returning simple error codes?

Introduction / Context:
Exceptions in C++ provide a powerful mechanism for handling error conditions, but they also come with costs. These costs are mostly related to what happens when an exception is actually thrown, not when code executes normally. This question asks why using exception objects can be considered more expensive than returning simple error codes in some situations.

Given Data / Assumptions:

• We are using C++ with standard exception support.
• Exception handling uses objects that carry information about the failure.
• When an exception is thrown, stack unwinding occurs and destructors are called for local objects.

Concept / Approach:
When an exception is thrown, the runtime must locate the appropriate handler, perform stack unwinding and manage the lifetime of the exception object. The exception object is typically constructed at the throw point and may be copied or moved as the runtime transfers control to a catch block. This process takes time and uses memory for the exception object and for the bookkeeping needed to unwind the stack. In contrast, returning a simple error code usually involves setting a return value and does not trigger stack unwinding. This is why exceptions are said to be more expensive when they are actually thrown, even though they have little or no overhead in the normal case where no exception occurs.

Step-by-Step Solution:
Step 1: Focus on what happens when an exception is thrown: creation of an exception object and stack unwinding.Step 2: Recognise that constructing and possibly copying exception objects consumes execution time and memory.Step 3: Option A states that this creation and destruction of exception objects during stack unwinding is the source of extra cost.Step 4: Option B incorrectly claims that exception objects are created for every successful call, which is not true.Step 5: Options C, D and E exaggerate or misrepresent the behaviour of exceptions, so option A is correct.

Verification / Alternative check:
Performance measurements often show that code where exceptions are never thrown runs at similar speed to code without exceptions. However, when an exception is thrown, the cost per event is high because the runtime must walk the call stack, destroy local objects and transfer control. This supports the idea that exceptions are more expensive at the moment of failure due to the work involved with exception objects and stack unwinding.

Why Other Options Are Wrong:
Option B is wrong because exception objects are created only when an exception is actually thrown, not on every function call. Option C suggests that optimisations are completely disabled for the entire program, which is not accurate; compilers can still perform many optimisations in the presence of exceptions. Option D claims that exception objects automatically delete all dynamic memory, which is not how exceptions work. Option E confuses compile time exception specifications with run time costs.

Common Pitfalls:
A common misconception is that exceptions are always slow, even when they are not thrown. In reality, most of the cost appears when an exception is raised. Another pitfall is using exceptions for normal control flow, which magnifies these costs unnecessarily. Good practice is to reserve exceptions for rare, exceptional conditions where their expressiveness outweighs the overhead.

Final Answer:
Because constructing, copying and destroying exception objects during stack unwinding consumes additional execution time and memory resources.