Повторить поведение спецификаций исключений под VC ++ 9.0 - PullRequest
2 голосов
/ 13 сентября 2009

Я работаю над старым кодом, который сильно зависит от поведения спецификаций исключений, описанных в стандарте языка. А именно, вызовы std :: surprise () при нарушении спецификации исключений в форме, описанной ниже.

foo() throw(T) { /*...*/ }

Спецификации Nothrow действительно гарантированно не выбрасывают, но ожидается, что throw (T) из них будут нарушены как из-за , так и ... хорошо, потому что стандарт ожидает столько же и предоставляет механизм для его обработки.

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

Однако теперь мне поручено включить новые и несвязанные функциональные возможности , и код работает не так, как ожидалось в VC ++ 9.0, из-за отклонения от стандартов, касающихся спецификаций исключений, введенных в 8.0. (ссылка: Microsoft )

Я пытаюсь найти способ заставить стандартное поведение. Надеялся, что компилятор предложит отступление. Но нет ни одного.

Мне не повезло, и мне нужно изменить правильно написанный стандартно-послушный код, работающий на 350 000 строк кода, с полностью развитой иерархией классов обработки ошибок? Или вы можете придумать способ, который поможет мне вызвать поведение std :: непредвиденный ()?

EDIT: Я предоставляю некоторую справочную информацию. Рассматриваемая система является Генератором Календарей Школьного Года для школы, в которой обучаются немногим более 4000 учеников. Я не уверен в том, что некоторые цифры пока есть, 6 классов и ~ 190 классов, плюс 12 виртуальных (дистанционное обучение) классы. MINGW исключен, как и любой другой компилятор, кроме VC ++ 8.0 или 9.0. Это связано с правилами, касающимися программного обеспечения, обслуживающего образовательную систему в этой стране.

Изменения, которые необходимо внести в код, предназначены именно для того, чтобы приспособить виртуальные классы к совершенно другой схеме для генерации календаря. И тут я столкнулся с этой проблемой. Программное обеспечение интенсивно использует механизм исключений в нескольких частях процесса создания календаря в качестве средства управления рабочим процессом с помощью как неожиданных () сопоставлений (сохраненных и восстановленных), так и сопоставлений bad_exception, ни одно из которых не работает в VC ++. С чисто личной точки зрения, я считаю, что механизм на самом деле очень элегантный, даже если он совершенно необычен. Но я отвлекся.

Ответы [ 2 ]

4 голосов
/ 13 сентября 2009

Я не верю, что поведение спецификации исключений Visual C ++ когда-либо (или утверждалось, что) соответствовало стандартам - даже до 8.0 - поэтому я не уверен, как работает приложение.

Возможно ли выполнить такие изменения, как:

void f() throw(T)
{
    // ...
}

до:

void f()
{
    try
    {
        // ...
    }
    catch (T)
    {
        throw;
    }
    catch (...)
    {
        app_unexpected();
    }
}
1 голос
/ 13 сентября 2009

Как вы упомянули, Visual Studio имеет "интересный" способ работы со спецификациями исключений:

  • throw() имеет свое нормальное значение (функция не должна бросать)
  • все остальное (включая спецификацию исключений) интерпретируется как throw(...)

Нет способа обойти это. Тем не менее, сообщество C ++ в значительной степени соглашается с тем, что спецификации исключений бесполезны. Вы действительно нуждаетесь в проверке во время выполнения брошенных типов ошибок? Возможно, правильное модульное тестирование может заменить ваши проверки во время выполнения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...