Почему pthread_exit бросает что-то пойманное многоточием?

если функция, называемая pthread_create, имеет следующую структуру

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

Почему обработчик исключений для эллипсиса вызывается при выполнении pthread_exit? (обратите внимание, что std::exception, например, не выбрасывается)

Ответ 1

По крайней мере, в GCC pthread_exit может выдать исключение ___forced_unwind, которое используется для разматывания стека при выходе из потока. Он не наследуется от std::exception и поэтому не может быть пойман как единое целое. Если вы поймаете это исключение, обязательно re- throw оно сможет выполнить свою работу:

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

Причина, по которой генерируется исключение, заключается в том, что pthread_exit указано, что никогда не возвращается. Наличие команды throw гарантирует очистку переменных, размещенных в стеке, и отсутствие выполнения кода после его расположения (если только вы не перехватите исключение unwind...). Однако это не переносимо, и, например, Clang использует совершенно другой механизм.

Кстати, это еще один случай, когда идиома catch (...) приносит больше вреда, чем пользы. Иногда он используется для "стабилизации" кода, который генерирует неизвестные исключения. Но это только откладывает видимость ущерба на более позднее время и место, делая невозможным выявление реального источника проблемы. Единственная разумная вещь, которую можно сделать в таком улове, - это минимальная очистка, возможно, регистрация, а затем повторная обработка. Процесс, который аварийно завершает работу из-за необработанного исключения, выглядит не очень красиво, но он может обеспечить отлаживаемый аварийный дамп, который четко показывает ошибочную команду. Но это только мое недовольство catch (...), которое едва связано с pthread_exit...