Por que não existe uma construção 'finalmente' em C ++?

O tratamento de exceções em C ++ é limitado a tentativa / lançamento / captura. Diferentemente do Object Pascal, Java, C # e Python, mesmo no C ++ 11, a finallyconstrução não foi implementada.

Tenho visto muita literatura C ++ discutindo "código de exceção seguro". Lippman escreve que o código seguro de exceção é um tópico importante, mas avançado e difícil, além do escopo de seu Primer - o que parece implicar que o código seguro não é fundamental para o C ++. Herb Sutter dedica 10 capítulos ao tópico em seu Excepcional C ++!

No entanto, parece-me que muitos dos problemas encontrados ao tentar escrever "código de exceção seguro" poderiam ser bem resolvidos se a finallyconstrução fosse implementada, permitindo ao programador garantir que, mesmo no caso de uma exceção, o programa possa ser restaurado para um estado seguro, estável e sem vazamentos, próximo ao ponto de alocação de recursos e código potencialmente problemático. Como um programador experiente em Delphi e C #, uso try .. finalmente bloqueia bastante o código, assim como a maioria dos programadores nessas linguagens.

Considerando todos os 'sinos e assobios' implementados no C ++ 11, fiquei surpreso ao descobrir que 'finalmente' ainda não estava lá.

Então, por que a finallyconstrução nunca foi implementada em C ++? Não é realmente um conceito muito difícil ou avançado de entender e ajuda bastante o programador a escrever 'código seguro de exceção'.

Como alguns comentários adicionais sobre a resposta de @ Nemanja (que, uma vez que cita Stroustrup, é realmente a melhor resposta possível):

É realmente apenas uma questão de entender a filosofia e os idiomas do C ++. Veja o exemplo de uma operação que abre uma conexão com o banco de dados em uma classe persistente e precisa garantir que ela seja fechada se uma exceção for lançada. Isso é uma questão de segurança de exceção e se aplica a qualquer idioma com exceções (C ++, C #, Delphi ...).

Em uma linguagem que usa try/ finally, o código pode se parecer com isso:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

Simples e direto. Existem, no entanto, algumas desvantagens:

• Se a linguagem não possui destruidores determinísticos, eu sempre tenho que escrever o finallybloco, caso contrário, eu vazo recursos.
• Se DoRiskyOperationfor mais do que uma chamada de método única - se eu tiver algum processamento para fazer no trybloco -, a Closeoperação poderá acabar sendo um pouco decente da Openoperação. Não consigo escrever minha limpeza ao lado da minha aquisição.
• Se eu tiver vários recursos que precisam ser adquiridos e liberados de uma maneira segura para exceções, posso terminar com várias camadas profundas de try/ finallyblocks.

A abordagem C ++ seria assim:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

Isso resolve completamente todas as desvantagens da finallyabordagem. Ele tem algumas desvantagens, mas são relativamente pequenas:

• Há uma boa chance de você precisar escrever a ScopedDatabaseConnectionclasse. No entanto, é uma implementação muito simples - apenas 4 ou 5 linhas de código.
• Isso envolve a criação de uma variável local extra - da qual você aparentemente não é fã, com base no seu comentário sobre "constantemente criando e destruindo classes para confiar em seus destruidores para limpar sua bagunça é muito ruim" - mas um bom compilador otimizará de qualquer trabalho extra que uma variável local extra envolva. Um bom design de C ++ depende muito desses tipos de otimizações.

Pessoalmente, considerando essas vantagens e desvantagens, considero o RAII uma técnica muito preferível finally. Sua milhagem pode variar.

Por fim, como o RAII é um idioma tão bem estabelecido no C ++ e para aliviar os desenvolvedores de alguns dos encargos de escrever várias Scoped...classes, existem bibliotecas como ScopeGuard e Boost.ScopeExit que facilitam esse tipo de limpeza determinística.

De Por que o C ++ não fornece uma construção "finalmente"? nas perguntas frequentes sobre estilo e técnica C ++ de Bjarne Stroustrup :

Como o C ++ suporta uma alternativa quase sempre melhor: A técnica "aquisição de recursos é inicialização" (TC ++ PL3, seção 14.4). A idéia básica é representar um recurso por um objeto local, para que o destruidor do objeto local libere o recurso. Dessa forma, o programador não pode esquecer de liberar o recurso.

O motivo que o C ++ não possui finallyé porque não é necessário no C ++. finallyé usado para executar algum código, independentemente de uma exceção ocorreu ou não, o que quase sempre é algum tipo de código de limpeza. No C ++, esse código de limpeza deve estar no destruidor da classe relevante e o destruidor sempre será chamado, como um finallybloco. O idioma de usar o destruidor para sua limpeza é chamado RAII .

Dentro da comunidade C ++, pode haver mais discussões sobre o código 'exceção seguro', mas é quase igualmente importante em outros idiomas que possuem exceções. O ponto principal do código 'exceção segura' é que você pensa em que estado seu código é deixado se ocorrer uma exceção em qualquer uma das funções / métodos que você chama.
No C ++, o código 'exceção seguro' é um pouco mais importante, porque o C ++ não possui uma coleta de lixo automática que cuida de objetos que ficam órfãos devido a uma exceção.

A razão pela qual a segurança de exceção é discutida mais na comunidade C ++ provavelmente também decorre do fato de que em C ++ você precisa estar mais ciente do que pode dar errado, porque há menos redes de segurança padrão no idioma.

Outros discutiram o RAII como a solução. É uma solução perfeitamente boa. Mas isso realmente não explica por que eles não adicionaram finallytão bem, já que é uma coisa amplamente desejada. A resposta para isso é mais fundamental para o design e o desenvolvimento de C ++: durante todo o desenvolvimento de C ++, os envolvidos resistiram fortemente à introdução de recursos de design que podem ser alcançados usando outros recursos sem muita confusão e, especialmente, onde isso exige a introdução de novas palavras-chave que poderiam tornar o código antigo incompatível. Como o RAII fornece uma alternativa altamente funcional finallye você pode realmente criar o seu próprio finallyno C ++ 11 de qualquer maneira, houve poucas exigências.

Tudo que você precisa fazer é criar uma classe Finallyque chame a função passada para seu construtor em seu destruidor. Então você pode fazer isso:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

A maioria dos programadores nativos de C ++ prefere, em geral, objetos RAII projetados de maneira limpa.

Você pode usar um padrão de "interceptação" - mesmo que não queira usar o bloco try / catch.

Coloque um objeto simples no escopo necessário. No destruidor desse objeto, coloque sua lógica "final". Não importa o que, quando a pilha for desenrolada, o destruidor do objeto será chamado e você receberá seu doce.

Bem, você pode finallycriar o seu próprio método, usando o Lambdas, que compilaria o seguinte (usando um exemplo sem RAII, é claro, não o melhor código):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

Veja este artigo .

Não tenho certeza se concordo com as afirmações aqui de que RAII é um superconjunto finally. O calcanhar de Aquiles da RAII é simples: exceções. O RAII é implementado com destruidores e sempre é errado no C ++ jogar fora de um destruidor. Isso significa que você não pode usar RAII quando precisar do seu código de limpeza. Se finallyimplementado, por outro lado, não há razão para acreditar que não seria legal jogar de um finallybloco.

Considere um caminho de código como este:

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

Se tivéssemos finally, poderíamos escrever:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

Mas não há como obter o comportamento equivalente usando RAII.

Se alguém sabe como fazer isso em C ++, estou muito interessado na resposta. Eu ficaria feliz com algo que dependesse, por exemplo, de impor todas as exceções herdadas de uma única classe com alguns recursos especiais ou algo assim.