Revertir el comportamiento de las especificaciones de excepción en VC ++ 9.0

Question

Estoy trabajando en un código antiguo que depende en gran medida del comportamiento de las especificaciones de excepción descrito en el estándar de idioma. A saber, llamadas a std :: unexpected () en violaciones de especificación de excepción del formulario que se describe a continuación.

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

Las especificaciones de Nothrow están garantizadas para no lanzar, pero se espera que las throw (T) sean violadas tanto por diseño como ... bueno, porque el estándar espera tanto y proporciona un mecanismo para manejarlo.

Las razones de esto están vinculadas a la decisión de los diseñadores de usar EH también como un mecanismo de manejo de errores (controlado por su propia jerarquía de clase de error) además del manejo de excepciones. El idioma presentado en EH se correlacionó estrechamente con sus necesidades y tomaron el camino de menor esfuerzo. Al menos así es como lo veo y no es particularmente impactante para mí, dado el tamaño y la complejidad del sistema.

Sin embargo, ahora tengo la tarea de incluir funcionalidad nueva y no relacionada y el código no se comporta como se esperaba en VC ++ 9.0, debido a la desviación de los estándares con respecto a las especificaciones de excepción introducidas en 8.0. (referencia: Microsoft )

Estoy tratando de encontrar una manera de forzar el comportamiento estándar. Esperaba que el compilador ofreciera una alternativa. Pero no hay ninguno.

¿No tengo suerte y necesito cambiar correctamente el código estándar obediente que se ejecuta en las 350,000 líneas de código con una jerarquía de clases de manejo de errores completamente desarrollada? ¿O puedes pensar en una forma que me ayude a forzar el comportamiento std :: inesperado ()?

EDITAR: Estoy proporcionando información de fondo. El sistema en cuestión es un generador de calendarios del año escolar para una escuela que atiende a un poco más de 4,000 estudiantes distribuidos, todavía no estoy seguro de algunos de los números, 6 grados y ~ 190 clases, más 12 virtuales (enseñanza a larga distancia) clases MINGW está fuera de discusión al igual que cualquier compilador que no sea VC ++ 8.0 o 9.0. Esto se debe a las regulaciones relacionadas con el software que sirve al Sistema Educativo en este país.

Los cambios necesarios para el código son exactamente para acomodar la introducción de las clases virtuales con un esquema muy diferente para la generación del calendario. Y luego me encontré con este problema. El software hace un uso intensivo del mecanismo de excepciones en algunas partes del proceso de generación del calendario como un medio para controlar el flujo de trabajo a través de asignaciones inesperadas () (guardadas y restauradas) y asignaciones de mala_excepción, ninguna de las cuales funciona bajo VC ++. En una nota puramente personal, encuentro que el mecanismo en su lugar es realmente muy elegante, incluso si es completamente poco común. Pero me estoy desviando.

Answer 1

Como mencionó, Visual Studio tiene un "interesante" forma de lidiar con las especificaciones de excepción:

• throw () tiene su significado normal (la función no debe lanzar)
• cualquier otra cosa (incluida la especificación sin excepción) se interpreta como throw(...)

No hay forma de evitar esto. Sin embargo, la comunidad C ++ está bastante de acuerdo en que las especificaciones de excepción son inútiles. ¿Realmente necesita una verificación en tiempo de ejecución de los tipos de error arrojados? Quizás las pruebas unitarias adecuadas puedan reemplazar sus comprobaciones de tiempo de ejecución.

Answer 2

No creo que el comportamiento de especificación de excepción de Visual C ++ haya sido (o se haya afirmado que cumple) los estándares, incluso antes de 8.0, por lo que no estoy seguro de cómo ha estado funcionando la aplicación.

¿Es factible realizar cambios como:

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

a:

void f()
{
    try
    {
        // ...
    }
    catch (T)
    {
        throw;
    }
    catch (...)
    {
        app_unexpected();
    }
}