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