¿Escribes (realmente) código seguro de excepción? [cerrado]

Su pregunta hace una afirmación, que "Escribir código seguro para excepciones es muy difícil". Voy a responder a sus preguntas primero, y luego, responder a la pregunta oculta detrás de ellos.

Respondiendo preguntas

¿Realmente escribes código seguro de excepción?

Por supuesto que sí.

Esta es la razón por la que Java perdió mucho de su atractivo para mí como programador de C++ (falta de semántica RAII), pero estoy divagando: Esta es una pregunta de C++.

It es, de hecho, necesario cuando se necesita trabajar con código STL o Boost. Por ejemplo, los subprocesos de C++ (boost::thread o std::thread) lanzarán una excepción para salir correctamente.

¿Está seguro de que su último código "listo para producción" es seguro para excepciones?

¿Puedes estar seguro de que lo es?

Escribir código seguro para excepciones es como escribir código libre de errores.

No puede estar 100% seguro de que su código sea seguro para excepciones. Pero entonces, te esfuerzas por ello, usando patrones bien conocidos, y evitando anti-patrones bien conocidos.

¿Conoce y/o realmente utiliza alternativas que funcionan?

No hay alternativas viables en C++ (es decir, tendrá que volver a C y evitar las bibliotecas de C++, así como sorpresas externas como Windows SEH).

Escribir código seguro de excepción

Para escribir código seguro de excepción, debe saber primero qué nivel de seguridad de excepción es cada instrucción que escribe.

Para ejemplo, un new puede lanzar una excepción, pero asignar un built-in (por ejemplo, un int, o un puntero) no fallará. Un intercambio nunca fallará (nunca escriba un intercambio de lanzamiento), un std::list::push_back puede lanzar...

Garantía de excepción

Lo primero que debe entender es que debe ser capaz de evaluar la garantía de excepción ofrecida por todas sus funciones:

1. none: Tu código nunca debería ofrecer eso. Este código filtrará todo y se descompondrá al principio excepción lanzada.
2. basic : Esta es la garantía que debe ofrecer como mínimo, es decir, si se lanza una excepción, no se filtran recursos, y todos los objetos siguen siendo completos
3. strong: El procesamiento tendrá éxito o lanzará una excepción, pero si lanza, entonces los datos estarán en el mismo estado que si el procesamiento no se hubiera iniciado en absoluto (esto le da una potencia transaccional a C++)
4. nothrow / nofail : El procesamiento éxito.

Ejemplo de código

El siguiente código parece C++ correcto, pero en verdad, ofrece la garantía de "ninguno", y por lo tanto, no es correcto:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   X * x = new X() ;                // 2. basic : can throw with new and X constructor
   t.list.push_back(x) ;            // 3. strong : can throw
   x->doSomethingThatCanThrow() ;   // 4. basic : can throw
}

Escribo todo mi código con este tipo de análisis en mente.

La garantía más baja ofrecida es básica, pero entonces, el orden de cada instrucción hace que toda la función sea "ninguna", porque si 3. lanza, x se filtrará.

Lo primero a hacer sería hacer la función "básica", es decir poner x en un puntero inteligente hasta que sea propiedad segura de la lista:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   std::auto_ptr<X> x(new X()) ;    // 2.  basic : can throw with new and X constructor
   X * px = x.get() ;               // 2'. nothrow/nofail
   t.list.push_back(px) ;           // 3.  strong : can throw
   x.release() ;                    // 3'. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 4.  basic : can throw
}

Ahora, nuestro código ofrece una garantía "básica". Nada se filtrará, y todos los objetos estarán en un estado correcto. Pero podríamos ofrecer más, es decir, la fuerte garantía. Aquí es donde puedevolverse costoso, y esta es la razón por la que no todo el código de C++ es fuerte. Vamos a intentarlo:

void doSomething(T & t)
{
   // we create "x"
   std::auto_ptr<X> x(new X()) ;    // 1. basic : can throw with new and X constructor
   X * px = x.get() ;               // 2. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 3. basic : can throw

   // we copy the original container to avoid changing it
   T t2(t) ;                        // 4. strong : can throw with T copy-constructor

   // we put "x" in the copied container
   t2.list.push_back(px) ;          // 5. strong : can throw
   x.release() ;                    // 6. nothrow/nofail
   if(std::numeric_limits<int>::max() > t2.integer)  // 7.   nothrow/nofail
      t2.integer += 1 ;                              // 7'.  nothrow/nofail

   // we swap both containers
   t.swap(t2) ;                     // 8. nothrow/nofail
}

Reordenamos las operaciones, primero creando y ajustando X a su valor correcto. Si alguna operación falla, entonces t no se modifica, por lo que la operación 1 a 3 puede considerarse "fuerte": Si algo se lanza, t no se modifica, y X no se filtrará porque es propiedad del puntero inteligente.

Luego, creamos una copia t2 de t, y trabajamos en esta copia desde la operación 4 a la 7. Si algo se lanza, t2 se modifica, pero entonces, t sigue siendo el original. Todavía ofrecemos la garantía fuerte.

Luego, intercambiamos t y t2. Las operaciones de swap deberían ser nothrow en C++, así que esperemos el intercambio para el que escribiste T es nothrow (si no lo es, reescríbelo para que sea nothrow).

Entonces, si llegamos al final de la función, todo tuvo éxito (Sin necesidad de un tipo de retorno) y t tiene su valor exceptuado. Si falla, entonces t tiene todavía su valor original.

Ahora, ofrecer la garantía fuerte podría ser bastante costoso, así que no se esfuerce por ofrecer la garantía fuerte a todo su código, pero si puede hacerlo sin un costo (y C++ inlining y otra optimización podría hacer todo el código anterior sin costo), a continuación, hacerlo. El usuario de la función te lo agradecerá.

Conclusión

Se necesita algún hábito para escribir código seguro de excepciones. Tendrá que evaluar la garantía ofrecida por cada instrucción que utilizará, y luego, tendrá que evaluar la garantía ofrecida por una lista de instrucciones.

Por supuesto, el compilador de C++ no respaldará la garantía (en mi código, ofrezco la garantía como una etiqueta @ warning doxygen), lo cual es un poco triste, pero debería no le impide intentar escribir código seguro de excepciones.

Fallo normal vs. error

¿Cómo puede un programador garantizar que una función no-fail siempre tendrá éxito? Después de todo, la función podría tener un error.

Esto es cierto. Se supone que las garantías de excepción son ofrecidas por código libre de errores. Pero entonces, en cualquier idioma, llamar a una función supone que la función está libre de errores. Ningún código cuerdo se protege contra la posibilidad de que tenga un error. Escribe el código mejor que tú puede, y luego, ofrecer la garantía con la suposición de que está libre de errores. Y si hay un error, corríjalo.

Las excepciones son para errores de procesamiento excepcionales, no para errores de código.

Últimas palabras

Ahora, la pregunta es "¿Vale la pena?".

Por supuesto, lo es. Tener una función "nothrow / no-fail" saber que la función no fallará es una gran bendición. Lo mismo puede decirse de una función "fuerte", que le permite escribir código con semántica transaccional, al igual que las bases de datos, con características de commit/rollback, el commit es la ejecución normal del código, lanzando excepciones es el rollback.

Entonces, lo "básico" es la garantía mínima que debe ofrecer. C++ es un lenguaje muy fuerte allí, con sus alcances, lo que le permite evitar cualquier fuga de recursos (algo que un recolector de basura encontraría difícil ofrecer para la base de datos, la conexión o los manejadores de archivos).

Así que, hasta donde yo lo veo, vale se.

Editar 2010-01-29: Sobre el intercambio no lanzador

Nobar hizo un comentario que creo, es bastante relevante, porque es parte de"cómo escribir código seguro de excepción":

• [me] Un intercambio nunca fallará (ni siquiera escriba un intercambio de lanzamiento)
• [nobar] Esta es una buena recomendación para funciones personalizadas swap(). Cabe señalar, sin embargo, que std::swap() puede fallar en función de las operaciones que utiliza internamente

El valor predeterminado std::swap hará copias y asignaciones, que, para algunos objetos, puede lanzar. Por lo tanto, el swap predeterminado podría lanzar, ya sea utilizado para sus clases o incluso para las clases STL. En lo que respecta al estándar C++, la operación de intercambio para vector, deque, y list no lanzará, mientras que podría para map si el funtor de comparación puede lanzar en la construcción de copia (Véase El Lenguaje de programación C++, Edición Especial, apéndice E, E. 4.3.Swap ).

Mirando la implementación de Visual C++ 2008 de el intercambio del vector, el intercambio del vector no lanzará si los dos vectores tienen el mismo asignador (es decir, el caso normal), pero hará copias si tienen diferentes asignadores. Y por lo tanto, supongo que podría tirar en este último caso.

Por lo tanto, el texto original todavía se mantiene: No escriba nunca un intercambio de lanzamiento, pero debe recordarse el comentario de nobar: Asegúrese de que los objetos que está intercambiando tengan un intercambio de no lanzamiento.

Editar 2011-11-06: Interesante artículo

Dave Abrahams, quien nos dio las garantías basic/strong/nothrow, describió en un artículo su experiencia sobre hacer segura la excepción STL:

Http://www.boost.org/community/exception_safety.html

Mire el punto 7 (Pruebas automatizadas para la excepción-seguridad), donde se basa en pruebas unitarias automatizadas para asegurarse de que cada caso sea probado. Supongo que esta parte es una excelente respuesta a la pregunta del autor " ¿Puede incluso estar seguro de que es?".

Editar 31-05-2013: Comentario de dionadar

t.integer += 1; es sin la garantía de que el desbordamiento no va a suceder NO excepción seguro, y de hecho puede invocar técnicamente UB! (Signed overflow is UB: C++11 5/4 "Si durante la evaluación de una expresión, el resultado no está definido matemáticamente o no está en el rango de valores representables para su tipo, el comportamiento es indefinido.") Tenga en cuenta que los enteros sin signo no se desbordan, pero hacer sus cálculos en una clase de equivalencia módulo 2^ # bits.

Dionadar se refiere a la siguiente línea, que de hecho tiene un comportamiento indefinido.

   t.integer += 1 ;                 // 1. nothrow/nofail

La solución aquí es verificar si el entero ya está en su valor máximo (usando std::numeric_limits<T>::max()) antes de hacer la adición.

Mi error iría en la sección "Fallo normal vs.bug", es decir, un bug. No invalida el razonamiento, y no significa que el código exception-safe sea inútil porque sea imposible de alcanzar. Usted no puede protegerse contra el apagado de la computadora, o errores del compilador, o incluso sus errores u otros errores. No puedes alcanzar la perfección, pero puedes tratar de acercarte lo más posible.

Corregí el código con el comentario de Dionadar en mente.