¿Se puede lanzar una excepción desde un destructor y atraparla?

Se puede, pero se recomienda encarecidamente no hacerlo. Lanzar una excepción desde un destructor puede conducir a un comportamiento indefinido, especialmente si el destructor se llama durante la propagación de otra excepción.

#include <iostream>
#include <stdexcept>

struct Resource {
    ~Resource() {
        // Se recomienda encarecidamente no lanzar excepciones desde un destructor
        std::cerr << "Se llama al destructor Resource." << std::endl;
        // throw std::runtime_error("Excepción desde el destructor Resource");
    }
};

void func_with_exception() {
    Resource r;
    throw std::runtime_error("Excepción en func_with_exception");
}

int main() {
    try {
        func_with_exception();
    } catch (const std::exception& e) {
        // Si se lanza una excepción desde un destructor durante la propagación de la pila
        // aquí puede ocurrir terminate() u otro comportamiento indefinido.
        std::cerr << "Excepción capturada: " << e.what() << std::endl;
    }
    return 0;
}

Razones principales por las que no se deben lanzar excepciones desde destructores:

• Excepciones dobles: Si el destructor se llama durante el manejo de otra excepción (por ejemplo, durante la propagación de la pila), lanzar una nueva excepción resultará en la existencia simultánea de dos excepciones activas, lo cual es comportamiento indefinido y puede llamar a std::terminate().
• Limpieza incompleta de recursos: Si en el destructor ocurre un error y se lanza una excepción, las operaciones de limpieza posteriores en el mismo destructor pueden no ejecutarse, llevando a fugas de recursos u otros problemas.
• Gestión compleja de errores: Manejar excepciones desde destructores complica la lógica del programa y dificulta entender el flujo de ejecución.

En C++11 y versiones posteriores, los destructores se consideran noexcept por defecto, lo que significa que no deben lanzar excepciones. Si un destructor noexcept lanza una excepción, se llama inmediatamente a std::terminate(). Para permitir que un destructor lance excepciones, debe declararse explícitamente como noexcept(false).

#include <iostream>
#include <stdexcept>

struct ResourceMayThrow {
    ~ResourceMayThrow() noexcept(false) {
        std::cerr << "Se llama al destructor ResourceMayThrow." << std::endl;
        // En este caso, se puede lanzar una excepción, pero aún así no se recomienda
        // throw std::runtime_error("Excepción desde el destructor ResourceMayThrow");
    }
};

int main() {
    try {
        ResourceMayThrow r;
        // Si aquí ocurre una excepción y el destructor también lanza una excepción,
        // esto resultará en std::terminate().
    } catch (const std::exception& e) {
        std::cerr << "Excepción capturada en main: " << e.what() << std::endl;
    }
    return 0;
}

En lugar de lanzar excepciones desde destructores, se recomiendan los siguientes enfoques para manejar errores al liberar recursos:

• Devolver un código de error: Si el destructor puede fallar, la estructura puede mantener una bandera de error que se pueda verificar después de la eliminación.
• Registro de errores: Registrar errores durante la liberación de recursos en un archivo de registro o en la salida estándar de errores.
• Implementar funciones close() o release(): Proporcionar una función separada para cerrar explícitamente el recurso, que puede lanzar excepciones, y llamarla antes de que el objeto salga del ámbito. Los objetos RAII deben garantizar la liberación de recursos en sus destructores, incluso si no se llama explícitamente a close().

Enfoque	¿Se recomienda?	Notas
Lanzar excepción	No	Puede llevar a std::terminate() y comportamiento indefinido.
Devolver código de error	Sí (si es necesario)	Requiere verificar explícitamente el error después de usar el objeto.
Registro de errores	Sí	Útil para depuración, pero no detiene la ejecución del programa.
Función close/release	Sí	Permite manejar errores explícitamente al liberar, el destructor es seguro.

En general, un destructor seguro es aquel que nunca lanza excepciones, lo cual es parte del principio RAII (Adquisición de Recursos con Inicialización).