Revert Ausnahme Spezifikationen Verhalten unter VC ++ 9.0

Question

Ich arbeite an alten Code, der in der Sprache Standard beschrieben stark auf die Ausnahme-Spezifikationen Verhalten beruht. Das heißt, ruft std :: unerwartet () auf Ausnahmespezifikation Verletzungen der nachfolgend beschriebenen Form.

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

nothrow Spezifikationen sind in der Tat garantiert nicht werfen, aber throw (T) sind diejenigen erwarten beide verletzt werden nach Design und ... na ja, weil der Standard erwartet so viel und stellt einen Mechanismus es zu behandeln.

Die Gründe hierfür sind der Designer Entscheidung gebunden des Verwendens EH auch als Fehlerbehandlungsmechanismus (gesteuert durch eigene Fehlerklassenhierarchie) zusätzlich zu Ausnahmebehandlung. Das Idiom präsentiert in EH abgebildet eng an ihre Bedürfnisse und sie nahmen den Weg des geringsten Aufwand. Dies ist zumindest wie ich es sehe und ist nicht besonders schockierend für mich, angesichts der Größe und Komplexität des Systems.

Ich bin aber jetzt damit beauftragt ist neue und andersartigen Funktionalität und der Code verhält sie nicht wie erwartet unter VC ++ 9.0, aufgrund der Abweichung von den Standards in Bezug auf Ausnahme Spezifikationen in 8.0 eingeführt. (Referenz: Microsoft )

Ich versuche, einen Weg zu finden, das Standardverhalten zu erzwingen. Hoffte für einen Rückfall vom Compiler angeboten werden. Aber es gibt keine.

Bin ich kein Glück und müssen korrekt geschrieben Standard-gehorsamen Code ändern auf den 350.000 Zeilen Code ausgeführt wird mit einer voll entwickelten Fehlerbehandlung Klassenhierarchie? Oder kann denken Sie an einen Weg, der mich std :: unerwartet () Verhalten zu zwingen helfen?

EDIT: Ich Bereitstellung einige Hintergrundinformationen. Das fragliche System ist ein Schuljahr Kalender-Generator für eine Schule unter etwas mehr als 4.000 Studenten verteilt dienen, ich bin nicht sicher, einige der Zahlen noch, 6 Sorten und ~ 190 Klassen, plus 12 virtuelle (Fernunterricht) Klassen. Mingw ist indiskutabel wie jeder andere als Compiler VC ++ 8.0 oder 9.0. Dies ist auf Vorschriften in Bezug auf Software, die in diesem Land, das Bildungssystem zu dienen.

Die Änderungen am Code erforderlich sind genau die Einführung der virtuellen Klassen mit einem sehr unterschiedlichen Schema für Kalender Generation gerecht zu werden. Und dann stieß ich auf dieses Problem. Die Software macht intensiven Gebrauch von dem Ausnahmemechanismus auf einigen Teilen des Kalendererzeugungsprozesses als Mittel Workflow durch beiden unerwarteten () Zuordnungen zu steuern (gespeichert und wiederhergestellt) und bad_exception Zuordnungen, von denen keine Arbeit unter VC ++. Auf rein persönliche Note, finde ich den Mechanismus, durch den eigentlich sehr elegant, auch wenn völlig ungewöhnlich. Aber ich schweife ab.

Answer 1

Wie Sie erwähnt haben, Visual Studio hat eine „interessante“ Art und Weise mit Ausnahme Spezifikationen des Umgangs:

• throw() hat seine normale Bedeutung (die Funktion darf nicht werfen)
• alles andere (einschließlich ohne Ausnahme Spezifikation) als throw(...) interpretiert

Es gibt keine Möglichkeit, dies zu umgehen. Allerdings stimmt die C ++ Gemeinschaft so ziemlich, dass die Ausnahme-Spezifikationen sind nutzlos. Benötigen Sie wirklich Runtime Überprüfung von Fehlertypen geworfen? Vielleicht richtige Testeinheit können Sie Ihre Laufzeitprüfungen ersetzen.

Answer 2

Ich glaube nicht, dass Visual C ++ Ausnahmespezifikation Verhalten je zuvor (oder beansprucht worden zu sein) Standards entsprechen - noch vor 8.0 -. So bin ich nicht sicher, wie die Anwendung gearbeitet hat

Ist es möglich, Änderungen durchzuführen, wie zum Beispiel:

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

zu:

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