catch() проглатывает все остальные уловы в xcode llvm 3.0

Я пытаюсь запустить googletest в моем проекте С++, и часть этого связана с использованием 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, но мог получить любую информацию о типе в этом контексте.

Кто-нибудь сталкивался с этим раньше или есть идеи?

ИЗМЕНИТЬ:

Поэтому я также связывался с libprofile_rt.dylib вместе с флагами компилятора -fprofile-arcs -fprofile-coverage. Удаление флага компилятора -fprofile-arcs устранило проблему. Раздражает, потому что это нарушает мои отчеты о покрытии.

(При связывании с librpofile_rt.a были те же проблемы)

Наверняка я не единственный, кто это видит, поскольку LLVM якобы использует googletest для своих тестовых случаев?!

Не знаю, следует ли мне опубликовать это как ответ или может прийти кто-то более знающий и предложить реальное решение.


person Soup    schedule 29.03.2012    source источник
comment
Не ответ, но обычно вы должны ловить по неконстантной ссылке, а не по константной ссылке или значению.   -  person Potatoswatter    schedule 29.03.2012
comment
Возможно, вы захотите попробовать более новую версию clang; начиная с компилятора Apple LLVM 3.0, были внесены некоторые существенные исправления для обработки исключений.   -  person servn    schedule 02.04.2012
comment
Да, заманчиво пойти по пути самостоятельной разработки, но не так хорошо для интеграции в команду, если только все не готовы к этому...   -  person Soup    schedule 05.04.2012


Ответы (1)


Подождав немного, похоже, что для этого нет известного решения, поэтому я опубликую свой ответ, как указано выше. Это может быть исправлено в Xcode 4.3

Поэтому я также связывался с libprofile_rt.dylib вместе с флагами компилятора -fprofile-arcs -fprofile-coverage. Удаление флага компилятора -fprofile-arcs устранило проблему. Раздражает, потому что это нарушает мои отчеты о покрытии.

(При связывании с librpofile_rt.a были те же проблемы)

Наверняка я не единственный, кто это видит, поскольку LLVM якобы использует googletest для своих тестовых случаев?!

person Soup    schedule 05.04.2012