¿por qué pthread_exit arroja algo atrapado por elipsis?

Question

si la función llamada por pthread_create tiene la siguiente estructura

try{ 
    ...code.... 
    pthread_detach(pthread_self()); 
    pthread_exit(NULL); 
}catch(...){ 
    std::cout<<"I am here"<<std::endl; 
} 

¿por qué el controlador de excepciones para los puntos suspensivos ser llamado por la ejecución de pthread_exit? (tenga en cuenta que std::exception, por ejemplo, están sin torcer)

Answer 1

pthread_exit podría lanzar una excepción ___forced_unwind, que se utiliza para desconectar la pila durante la salida de rosca. No hereda de std::exception y, por lo tanto, no se puede capturar como uno solo. Si usted coge esa excepción, asegúrese de volver a throw que lo que puede hacer su trabajo:

try { 
... 
} catch (abi::___forced_unwind&) { 
    throw; 
} catch (...) { 
    // whatever 
} 

La razón se produce una excepción es que pthread_exit se especifica para no volver jamás. Tenerlo arroja garantiza la limpieza de las variables asignadas por la pila, y la no ejecución del código después de su ubicación (a menos que detecte la excepción de desenrollado ...).

Por cierto, este es otro caso donde la expresión catch (...) hace más daño que bien. A veces se usa para "estabilizar" el código que arroja excepciones desconocidas. Pero eso solo difiere la visibilidad del daño a un tiempo y lugar posterior, lo que hace imposible identificar el origen real del problema. Lo único razonable que se puede hacer en una captura como esta es la limpieza mínima, posiblemente la tala y luego volver a tirar. Un proceso que falla debido a una excepción no controlada no es una vista agradable, pero puede proporcionar un volcado de falla debugible que muestra claramente el comando defectuoso. Pero eso es solo mi rencor contra catch (...), que apenas se relaciona con pthread_exit ...