What is impact of throwing an exception from a destructor in C++?

Throwing an exception from a destructor in C++ is a bad idea and can lead to undefined behavior or program termination.

Why?

When an exception is thrown inside a destructor, and another exception is already in progress (like during stack unwinding from a previous exception), the C++ runtime calls std::terminate(), which immediately stops the program.

Example of What NOT to Do

#include <iostream>
#include <stdexcept>

class BadDestructor {
public:
    ~BadDestructor() {
        std::cout << "Destructor called\n";
        throw std::runtime_error("Exception from destructor!");  // BAD PRACTICE
    }
};

int main() {
    try {
        BadDestructor obj;
        throw std::runtime_error("Some error occurred");  // First exception
    } catch (const std::exception& e) {
        std::cout << "Caught exception: " << e.what() << '\n';
    }

    return 0;
}

Output (may vary, but likely crashes):

Destructor called
terminate called after throwing an instance of 'std::runtime_error'
Aborted (core dumped)

👉 Why? The first exception triggers stack unwinding, and when the destructor throws another one, C++ panics and calls std::terminate().

---

How to Handle It Properly

Instead of throwing an exception, log the error or handle it gracefully.

#include <iostream>

class SafeDestructor {
public:
    ~SafeDestructor() {
        try {
            // Simulate an issue
            throw std::runtime_error("Oops! Destructor issue.");
        } catch (const std::exception& e) {
            std::cerr << "Destructor handled error: " << e.what() << '\n';
        }
    }
};

int main() {
    SafeDestructor obj;  // No crash, just a logged message
    return 0;
}

Output:

Destructor handled error: Oops! Destructor issue.

👉 Fix: Catch the exception inside the destructor and handle it properly instead of letting it escape.

---

Takeaway

❌ Never let an exception escape a destructor—it can crash your program.
✅ If something goes wrong, log it, handle it, or use error codes instead.

💡 Best Practice: If an operation inside a destructor might fail, design your class so that failure is handled before destruction.