Las excepciones hacen que sea realmente fácil escribir código donde una excepción que se lanza romperá invariantes y dejará los objetos en un estado inconsistente. Básicamente, te obligan a recordar que casi todas las declaraciones que haces pueden arrojar y manejar eso correctamente. Hacerlo puede ser complicado y contrario a la intuición.
Considere algo como esto como un ejemplo simple:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
Suponiendo que la FrobManagervoluntad deletedel FrobObject, esto se ve bien, ¿verdad? O tal vez no ... Imagínense entonces si FrobManager::HandleFrob()o operator newlanza una excepción. En este ejemplo, el incremento de m_NumberOfFrobsno se revierte. Por lo tanto, cualquiera que use esta instancia de Frobbertendrá un objeto posiblemente dañado.
Este ejemplo puede parecer estúpido (ok, tuve que estirarme un poco para construir uno :-)), pero la conclusión es que si un programador no está pensando constantemente en excepciones y asegurándose de que cada permutación de estado se lleve a cabo siempre que hay lanzamientos, te metes en problemas de esta manera.
Como ejemplo, puede pensar en ello como si pensara en mutex. Dentro de una sección crítica, confía en varias declaraciones para asegurarse de que las estructuras de datos no estén dañadas y que otros subprocesos no puedan ver sus valores intermedios. Si alguna de esas declaraciones simplemente no se ejecuta al azar, terminará en un mundo de dolor. Ahora elimine los bloqueos y la concurrencia, y piense en cada método de esa manera. Piense en cada método como una transacción de permutaciones en el estado del objeto, por así decirlo. Al comienzo de la llamada al método, el objeto debe tener un estado limpio y, al final, también debe haber un estado limpio. En el medio, la variable foopuede ser inconsistente conbar, pero su código eventualmente lo rectificará. Lo que significan las excepciones es que cualquiera de sus declaraciones puede interrumpirlo en cualquier momento. La responsabilidad recae en usted en cada método individual para hacerlo bien y retroceder cuando eso suceda, u ordenar sus operaciones para que los lanzamientos no afecten el estado del objeto. Si se equivoca (y es fácil cometer este tipo de error), la persona que llama termina viendo sus valores intermedios.
Los métodos como RAII, que a los programadores de C ++ les encanta mencionar como la solución definitiva a este problema, ayudan en gran medida a protegerse contra esto. Pero no son una solución milagrosa. Se asegurará de que libere recursos en un lanzamiento, pero no lo liberará de tener que pensar en la corrupción del estado del objeto y en los llamadores que ven valores intermedios. Entonces, para mucha gente, es más fácil decirlo, por orden del estilo de codificación, sin excepciones . Si restringe el tipo de código que escribe, es más difícil introducir estos errores. Si no lo hace, es bastante fácil cometer un error.
Se han escrito libros completos sobre codificación segura de excepciones en C ++. Muchos expertos se han equivocado. Si es realmente tan complejo y tiene tantos matices, tal vez sea una buena señal de que debes ignorar esa característica. :-)