Rétablir le comportement des spécifications d'exception sous VC ++ 9.0

Question

Je travaille sur un ancien code qui s'appuie fortement sur le comportement des spécifications d'exception décrit dans le standard de langage. À savoir, les appels à std ::visible () sur les violations de spécification d'exception du formulaire décrit ci-dessous.

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

Les spécifications

de Nothrow sont en effet garanties de ne pas lancer, mais les tirs (T) devraient être violés à la fois de par leur conception et ... bien, car la norme en attend autant et fournit un mécanisme pour le gérer.

Les raisons en sont liées à la décision du concepteur d’utiliser EH également comme mécanisme de traitement des erreurs (contrôlé par sa propre hiérarchie de classes d’erreurs) en plus du traitement des exceptions. Le langage présenté dans EH correspondait étroitement à leurs besoins et ils empruntaient le chemin du moindre effort. C’est au moins ce que je vois et cela ne me choque pas particulièrement compte tenu de la taille et de la complexité du système.

Toutefois, je suis maintenant chargé d'inclure une nouvelle fonctionnalité non liée et le code ne se comporte pas comme prévu dans VC ++ 9.0, en raison d'un écart par rapport aux normes relatives aux spécifications d'exception introduites dans la version 8.0. (référence: Microsoft )

J'essaie de trouver un moyen de forcer le comportement standard. J'espérais qu'une solution de secours serait offerte par le compilateur. Mais il n'y en a pas.

Suis-je à court de chance et dois-je modifier un code conforme aux normes, correctement écrit, fonctionnant sur les 350 000 lignes de code avec une hiérarchie de classes de traitement des erreurs entièrement développée? Ou pouvez-vous penser à un moyen de m'aider à forcer le comportement std :: Inattendu ()?

MODIFIER: Je fournis des informations de base. Le système en question est un générateur de calendriers scolaires pour une école desservant un peu plus de 4 000 élèves répartis entre, je ne sais pas encore quel est le nombre de participants, 6 classes et ~ 190 classes, plus 12 classes virtuelles (enseignement à distance) Des classes. MINGW est hors de question, de même que tout compilateur autre que VC ++ 8.0 ou 9.0. Cela est dû aux réglementations relatives aux logiciels au service du système éducatif de ce pays.

Les modifications nécessaires au code concernent précisément l'introduction des classes virtuelles avec un schéma très différent pour la génération de calendrier. Et puis je suis tombé sur ce problème. Le logiciel utilise beaucoup le mécanisme des exceptions sur quelques parties du processus de génération de calendrier pour contrôler le flux de travail via des mappages inattendus () (enregistrés et restaurés) et mappages bad_exception, qui ne fonctionnent pas sous VC ++. Sur une note purement personnelle, je trouve le mécanisme en place très élégant même s’il est tout à fait inhabituel. Mais je m'égare.

Answer 1

Comme vous l'avez mentionné, Visual Studio dispose d'un "intéressant". manière de traiter les spécifications d'exception:

• throw () a sa signification normale (la fonction ne doit pas lancer)
• rien d'autre (y compris aucune spécification d'exception) est interprété comme throw (...)

Il n’ya aucun moyen de contourner cela. Cependant, la communauté C ++ convient que les spécifications d'exception sont inutiles. Avez-vous vraiment besoin de la vérification à l'exécution des types d'erreur générés? Peut-être que des tests unitaires appropriés peuvent remplacer vos contrôles d’exécution.

Answer 2

Je ne crois pas que le comportement de la spécification des exceptions Visual C ++ ait jamais été (ou prétendait être) conforme aux normes - même avant la 8.0 -, donc je ne suis pas sûr du fonctionnement de l'application.

Est-il possible d'effectuer des modifications telles que:

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

à:

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