Revert comportamento especificações excepção sob o VC ++ 9,0

Question

Eu estou trabalhando em código antigo que depende muito do comportamento especificações de exceção descrita no padrão de linguagem. Ou seja, as chamadas para std :: inesperado () sobre violações de especificação exceção da forma descrita abaixo.

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

não nothrow especificações são de fato garantido para jogar, mas throw (T) aqueles são esperados a ser violados ambos os por design porque os espera padrão e ... bem, tanto e fornece um mecanismo para lidar com isso.

As razões para isso são amarradas para a decisão desenhadores de usar EH também como um mecanismo para o tratamento de erro (controlado pelo seu próprio hierarquia de classe de erro) em adição ao tratamento de excepção. O idioma apresentado no EH perto mapeado para as suas necessidades e eles tomaram o caminho de menor esforço. Esta é, pelo menos, como eu vê-lo e não é particularmente chocante para mim, dado o tamanho ea complexidade do sistema.

Estou no entanto agora a tarefa de incluir novo e sem relação funcionalidade eo código não está se comportando conforme o esperado no VC ++ 9.0, devido ao desvio das normas sobre especificações de exceção introduzidos no 8.0. (Referência: Microsoft )

Eu estou tentando encontrar uma maneira de forçar o comportamento padrão. Estava esperando por uma reserva, que será oferecido pelo compilador. Mas não há nenhuma.

Am I fora da sorte e precisa mudar corretamente escrito código padrão-obediente em execução nos 350.000 linhas de código com uma hierarquia de classes totalmente desenvolvido tratamento de erros? Ou você pode pensar de uma maneira que vai me ajudar a força de std :: comportamento inesperado ()?

EDIT: Eu estou fornecendo algumas informações básicas. O sistema em questão é um Gerador de Calendários ano escolar de uma escola que serve um pouco mais de 4.000 estudantes distribuídos entre, estou inseguro quanto a alguns dos números ainda, 6 graus e ~ 190 aulas, além de (ensino à distância) 12 virtual Aulas. Mingw está fora de questão como é qualquer compilador diferente VC ++ 8,0 ou 9,0. Isto é devido a regulamentos relativos a software que servem o sistema educacional neste país.

As mudanças necessárias para o código são exatamente para acomodar a introdução das aulas virtuais com um esquema muito diferente para a geração de calendário. E então topei com este problema. O software faz uso intensivo do mecanismo de excepções em algumas partes do processo de geração de calendário como um meio de fluxo de trabalho de controlo por meio de ambos os mapeamentos inesperado (mapeamentos) bad_exception, (guardado e restaurado) e nenhum dos que funcionam sob o VC ++. Em uma nota puramente pessoal, acho que o mecanismo em vigor, na verdade, muito elegante, mesmo se totalmente incomum. Mas estou divagando.

Answer 1

Como você mencionou, Visual Studio tem uma forma "interessante" de lidar com especificações de exceção:

• throw() tem o seu significado normal (a função não deve jogar)
• qualquer outra coisa (incluindo sem especificação de exceção) é interpretado como throw(...)

Não há maneira de contornar isso. No entanto, a comunidade C ++ praticamente concorda que as especificações de exceção são inúteis. Você realmente precisa de tempo de execução verificação dos tipos de erros jogado? Talvez o teste de unidade adequada pode substituir seus cheques tempo de execução.

Answer 2

Eu não acredito que C ++ comportamento Visual especificação de exceção nunca foi (ou alegou ter sido) normas conformes - mesmo antes de 8.0 -. Por isso não tenho certeza de como a aplicação tem vindo a trabalhar

É viável para realizar mudanças, tais como:

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

para:

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