What should be kept in mind when calling exceptions…

When calling exceptions in a destructor, the following points should be remembered:

Unsafe and undefined behavior: Throwing an exception from a destructor during the handling of another exception (for example, during stack unwinding) leads to a call to std::terminate, which usually terminates the program. This is because the C++ standard does not define how to handle concurrent active exceptions.
Possible resource leaks: If a destructor that throws an exception is part of a complex object or data structure, other parts of this object or other objects may not be properly destroyed, which can lead to memory leaks or other resource leaks.
SLF and RAII: Destructors are a key component of the SLF (Scope-Locked Free) and RAII (Resource Acquisition Is Initialization) idioms, which rely on the guaranteed execution of destructors to release resources. An exception from a destructor violates this guarantee.
Exceptions that seem "safe" to throw: Strictly speaking, throwing exceptions from destructors is unsafe. If a situation arises where a destructor cannot perform its function correctly (for example, failing to write to a file during closing), the correct approach is to handle this error inside the destructor, log the problem, or set an error flag, rather than throwing an exception.
Noexcept: In C++11 and later, destructors are implicitly considered noexcept(true) by default. This means that if a destructor attempts to throw an exception, the program will be terminated (std::terminate). User-defined types' destructors without an explicit noexcept specifier are also implicitly considered noexcept(true) if they do not contain explicitly noexcept-qualified functions.

Overall, it is advisable to avoid throwing exceptions from destructors. If you need to report an error, use alternative mechanisms.

#include <iostream>
#include <fstream>
#include <exception>

class ResourceHandler {
public:
    ResourceHandler(const std::string& filename) : file_(filename) {
        if (!file_.is_open()) {
            throw std::runtime_error("Failed to open file");
        }
        std::cout << "Resource acquired (file opened)." << std::endl;
    }

    ~ResourceHandler() noexcept { // Preferably noexcept
        // Dangerous situation: what if flush() or close() throws an exception?
        // In the C++ standard, destructors of POD types and their aggregates do not throw exceptions
        // User-defined destructors are implicitly noexcept(true) in C++11,
        // if they do not contain functions explicitly declared as potentially throwing.

        if (file_.is_open()) {
             // Instead of throwing an exception:
             try {
                // If you need to write data during closing
                // file_.flush();
                file_.close();
             } catch (const std::exception& e) {
                 // Log the error in the destructor
                 std::cerr << "Error closing file in destructor: " << e.what() << std::endl;
                 // Do not throw an exception!
             }
            std::cout << "Resource released (file closed)." << std::endl;
        } else {
            std::cout << "Resource already released or failed to open." << std::endl;
        }
    }

private:
    std::ofstream file_;
};

int main() {
    try {
        ResourceHandler handler("test.txt");
        // Do something with the file...
        // For example, intentionally throw an exception for demonstration
        // throw std::runtime_error("Simulating error during processing");

    } catch (const std::exception& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
    }

    // The handler's destructor will be called automatically upon exiting the try block.
    // If the destructor throws an exception during exception handling
    // (for example, if we uncomment throw std::runtime_error),
    // std::terminate will be called.

    return 0;
}

What should be kept in mind when calling exceptions in a destructor?