Revert behavior of exception specification in VC ++ 9.0
I am working on old code that relies heavily on the behavior of exception specifications as described in the language standard. Namely, it calls std :: unexpected () when it violates the form exception specification described below.
foo() throw(T) { /*...*/ }
The Nothrow specs are really guaranteed not to be thrown, but outliers (T) are expected to be violated both by design and ... well, since the standard expects the same and provides a mechanism to handle it.
The reasons for this are due to the designers' decision to use EH as well as an error handling mechanism (controlled by its own error class hierarchy) in addition to exception handling. The idiom presented in EH is closely related to their needs and they took the path of least effort. This is at least the way I see it and doesn't shock me too much given the size and complexity of the system.
I have now been tasked with including new and unrelated functionality , and the code does not behave as expected in VC ++ 9.0 due to deviations from the standards regarding exception specifications introduced in 8.0. (ref: Microsoft )
I am trying to find a way to force the default behavior. Hope the compiler will offer a backup. But he is not.
Am I lucky and need to properly modify written standard-obedient code that runs on 350,000 lines of code, with a fully developed hierarchy of error handling classes? Or can you think of a way to help me force std :: unexpected () behavior?
EDIT: I provide some background information. The system in question is a school year calendar generator for a school with just over 4,000 students, among whom I am not sure about some of the rooms, 6 classes and ~ 190 classes plus 12 virtual (long distance courses) classes. MINGW is out of the question, like any compiler other than VC ++ 8.0 or 9.0. This is due to the regulations regarding software serving the education system in that country.
The changes required to the code are exactly in line with the implementation of virtual classrooms with a completely different schema for generating the calendar. And then I ran into this problem. The software makes heavy use of the exception mechanism in several parts of the calendar generation process as a workflow control through both unexpected () mappings (saved and restored) and bad_exception mappings, none of which work under VC ++. On a purely personal note, I believe that the mechanism is actually very elegant, even if it is unusual. But I'm distracted.
source to share
As you mentioned, Visual Studio has an "interesting" way to deal with exception specifications:
-
throw()
has its normal meaning (the function should not throw) - any other (including an exception specification) is interpreted as
throw(...)
There is no way around this. However, the C ++ community pretty much agrees that exception specifications are useless. Do you really need runtime error checking? Perhaps proper unit testing can replace your runtime checks.
source to share
I don't believe the behavior of the Visual C ++ BOM has ever been (or claimed to be) standards-compliant - even prior to 8.0 - so I'm not sure how the application works.
Is it possible to make changes like:
void f() throw(T)
{
// ...
}
in
void f()
{
try
{
// ...
}
catch (T)
{
throw;
}
catch (...)
{
app_unexpected();
}
}
source to share