Ripristinare il comportamento delle specifiche delle eccezioni in VC ++ 9.0

Question

Sto lavorando su un vecchio codice che si basa fortemente sul comportamento delle specifiche delle eccezioni descritto nello standard del linguaggio. Vale a dire, chiama a std :: unexpected () in caso di violazioni delle specifiche delle eccezioni del modulo descritto di seguito.

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

Le specifiche di Nothrow sono sicuramente garantite per non essere lanciate, ma si prevede che quelle lancio (T) vengano violate sia dal design che ... beh, perché lo standard prevede e fornisce un meccanismo per gestirlo.

Le ragioni di ciò sono legate alla decisione dei progettisti di utilizzare EH anche come meccanismo di gestione degli errori (controllato dalla propria gerarchia di classi di errori) oltre alla gestione delle eccezioni. Il linguaggio presentato in EH era strettamente connesso alle loro esigenze e presero la strada del minimo sforzo. Questo è almeno il modo in cui lo vedo e non è particolarmente scioccante per me, date le dimensioni e la complessità del sistema.

Ora sono ora incaricato di includere funzionalità nuove e non correlate e il codice non si comporta come previsto in VC ++ 9.0, a causa della deviazione dagli standard relativi alle specifiche delle eccezioni introdotte in 8.0. (riferimento: Microsoft )

Sto cercando di trovare un modo per forzare il comportamento standard. Sperava in un fallback di essere offerto dal compilatore. Ma non ce n'è.

Sono sfortunato e ho bisogno di cambiare il codice obbediente scritto correttamente in esecuzione sulle 350.000 righe di codice con una gerarchia di classi di gestione degli errori completamente sviluppata? Oppure puoi pensare a un modo che mi aiuterà a forzare il comportamento std :: unexpected ()?

Modifica Sto fornendo alcune informazioni di base. Il sistema in questione è un generatore di calendari per l'anno scolastico per una scuola che serve poco più di 4.000 studenti distribuiti tra, non sono ancora sicuro di alcuni numeri, 6 gradi e ~ 190 classi, più 12 virtuali (insegnamento a distanza) classi. MINGW è fuori discussione come qualsiasi altro compilatore diverso da VC ++ 8.0 o 9.0. Ciò è dovuto alle normative relative al software al servizio del sistema educativo in questo paese.

Le modifiche necessarie al codice sono esattamente per adattarsi all'introduzione delle classi virtuali con uno schema molto diverso per la generazione del calendario. E poi ho incontrato questo problema. Il software fa ampio uso del meccanismo delle eccezioni su alcune parti del processo di generazione del calendario come mezzo per controllare il flusso di lavoro tramite mappature inattese () (salvate e ripristinate) e bad_exception, nessuna delle quali funziona con VC ++. Su una nota puramente personale, trovo il meccanismo in atto in realtà molto elegante anche se del tutto insolito. Ma sto divagando.

Answer 1

Come hai detto, Visual Studio ha un "interessante" modo di trattare le specifiche delle eccezioni:

• throw () ha il suo significato normale (la funzione non deve essere lanciata)
• qualsiasi altra cosa (inclusa nessuna specifica di eccezione) viene interpretata come throw(...)

Non c'è modo di aggirare questo. Tuttavia, la comunità C ++ concorda praticamente sul fatto che le specifiche delle eccezioni sono inutili. Hai davvero bisogno di verificare il runtime dei tipi di errore generati? Forse un test di unità adeguato può sostituire i controlli di runtime.

Answer 2

Non credo che il comportamento delle specifiche delle eccezioni di Visual C ++ sia mai stato (o dichiarato essere stato) conforme agli standard - anche prima della 8.0 - quindi non sono sicuro di come l'applicazione abbia funzionato.

È possibile eseguire modifiche come:

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

a:

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