dlaczego pthread_exit rzuca coś złapanego przez ellipsis?

Question

jeśli funkcja wywoływana przez pthread_create ma następującą strukturę

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

dlaczego obsługi wyjątku dla elipsy sprawdzony przy realizacji pthread_exit? (uwaga std::exception, na przykład, nie są wyrzucane)

Answer 1

pthread_exit może wyjątek, ___forced_unwind, które są wykorzystywane do odwijania stosu podczas zjazdu gwintu. Nie dziedziczy po std::exception i dlatego nie może zostać przechwycony jako jeden. Jeśli nie złapać ten wyjątek, należy go ponownie throw dzięki czemu może wykonywać swoje zadania:

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

Powodem jest wyjątek jest to, że nigdy nie jest określony pthread_exit powrotu. Mając ten rzut, gwarantuje wyczyszczenie zmiennych przydzielonych do stosu i brak wykonania kodu po jego lokalizacji (chyba że zauważysz wyjątek odwijania ...).

BTW, to kolejny przypadek, w którym idiom catch (...) przynosi więcej szkód niż pożytku. Czasami jest używany do "stabilizacji" kodu, który rzuca nieznane wyjątki. Ale to tylko ogranicza widoczność uszkodzeń w późniejszym czasie i miejscu, uniemożliwiając identyfikację prawdziwego pochodzenia problemu. Jedyną rozsądną rzeczą do zrobienia w takim haczyku jest minimalne oczyszczanie, możliwie rejestrowanie, a następnie ponowne rzucanie. Proces, który zawiesza się z powodu nieobsługiwanego wyjątku, nie jest pięknym widokiem, ale może dostarczyć debugowalny zrzut awaryjny, który wyraźnie pokazuje błędne polecenie. Ale to tylko moja uraza do catch (...), która jest ledwo powiązana z pthread_exit ...