As exceções tornam realmente fácil escrever código onde uma exceção lançada quebrará invariantes e deixará objetos em um estado inconsistente. Eles essencialmente o forçam a lembrar que quase todas as afirmações que você faz podem potencialmente jogar e lidar com isso corretamente. Fazer isso pode ser complicado e contra-intuitivo.
Considere algo assim como um exemplo simples:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
Supondo FrobManagerque deleteo FrobObject, isso parece OK, certo? Ou talvez não ... Imagine então se FrobManager::HandleFrob()ou operator newlança uma exceção. Neste exemplo, o incremento de m_NumberOfFrobsnão é revertido. Portanto, qualquer pessoa que use essa instância de Frobberterá um objeto possivelmente corrompido.
Este exemplo pode parecer estúpido (ok, eu tive que me esforçar um pouco para construir um :-)), mas, a conclusão é que se um programador não está pensando constantemente em exceções e certificando-se de que todas as permutações de estado sejam roladas sempre que houver lançamentos, você terá problemas dessa forma.
Por exemplo, você pode pensar nisso como você pensa em mutexes. Dentro de uma seção crítica, você confia em várias instruções para garantir que as estruturas de dados não sejam corrompidas e que outros threads não possam ver seus valores intermediários. Se qualquer uma dessas declarações simplesmente não funcionar, você terminará em um mundo de dor. Agora tire os bloqueios e a simultaneidade e pense em cada método assim. Pense em cada método como uma transação de permutações no estado do objeto, se quiser. No início da chamada do método, o objeto deve estar em estado limpo e, no final, também deve haver um estado limpo. No meio, a variável foopode ser inconsistente combar, mas seu código acabará corrigindo isso. O que as exceções significam é que qualquer uma de suas declarações pode interrompê-lo a qualquer momento. A responsabilidade recai sobre você em cada método individual para acertar e reverter quando isso acontecer, ou ordenar suas operações para que os lançamentos não afetem o estado do objeto. Se você errar (e é fácil cometer esse tipo de erro), o chamador acaba vendo seus valores intermediários.
Métodos como o RAII, que os programadores de C ++ adoram mencionar como a solução definitiva para esse problema, ajudam muito na proteção contra isso. Mas eles não são uma bala de prata. Isso garante que você libere recursos imediatamente, mas não o livra de ter que pensar sobre a corrupção do estado do objeto e os chamadores vendo valores intermediários. Então, para muitas pessoas, é mais fácil dizer, por decreto de estilo de codificação, sem exceções . Se você restringir o tipo de código que escreve, é mais difícil introduzir esses bugs. Do contrário, é muito fácil cometer um erro.
Livros inteiros foram escritos sobre codificação segura de exceção em C ++. Muitos especialistas erraram. Se for realmente tão complexo e tiver tantas nuances, talvez seja um bom sinal de que você precisa ignorar esse recurso. :-)