Я пытаюсь запустить googletest в моем проекте c ++, и часть этого включает использование EXPECT_THROW(statement, expected_exception);
. Я использую XCode с выбранным «Apple LLVM Compiler 3.0». Все это на Snow Leopard 10.6.8, XCode 4.2.
Я не смог пройти ни один из этих тестов, даже при использовании явного фиктивного регистра EXPECT_THROW(throw std::runtime_error(), std::runtime_error);
После расширения макроса (из gtest / internal / gtest-internal.h: 1114 GTEST_TEST_THROW_) до
bool gtest_caught_expected = false;
try {
// GTEST_SUPPRESS_UNREACHABLE_CODE_WARNING_BELOW_(statement);
throw std::runtime_error("sigh");
}
// catch (expected_exception const&) {
catch (std::runtime_error const& e){
std::cout << "const ref caught" << std::endl;
gtest_caught_expected = true;
}
// added by me to check it wasn't a const& issue
catch (std::runtime_error e){
std::cout << "type caught" << std::endl;
gtest_caught_expected = true;
}
catch (...) {
//gtest_msg.value =
// "Expected: " #statement " throws an exception of type "
//#expected_exception ".\n Actual: it throws a different type.";
//goto GTEST_CONCAT_TOKEN_(gtest_label_testthrow_, __LINE__);
std::cout << "unknown caught" << std::endl;
}
затем, установив точку останова в gdb с помощью catch catch
и пройдя по ней, я вижу, что catch(runtime_errors)
пропущены, а catch(...)
выполняется. Если я закомментирую блок catch(...)
, будет выполнен правильный оператор catch(std::runtime_error const& e)
.
Установка моего компилятора на "LLVM GCC 4.2" устраняет проблему, но я хочу нацелиться на clang ++.
Мой отдельный тестовый пример EXPECT_THROW работает, когда он скомпилирован вручную с помощью clang ++ в командной строке, поэтому я полагаю, что это должна быть какая-то эзотерическая настройка xcode или llvm? Или, может быть, каким-то образом LLVM превращает обезьяну в мой runtime_error в какой-то другой тип? Я попытался catch throw
, но мог получить любую информацию о типе в этом контексте.
Кто-нибудь испытывал это раньше или есть идеи?
EDIT:
Так что я также связывался с libprofile_rt.dylib вместе с флагами компилятора -fprofile-arcs -fprofile-coverage
. Снятие флага компилятора -fprofile-arcs
устранило проблему. Раздражает, потому что это нарушает мои отчеты о покрытии.
(У связи с librpofile_rt.a были те же проблемы)
Конечно, я не единственный, кто это видит, поскольку LLVM предположительно использует googletest для своих тестовых случаев?!
Не уверен, стоит ли мне публиковать это как ответ или если кто-то более знающий может прийти и предложить реальное решение.