¿(Realmente) escribes código seguro de excepción? [cerrado]

Su pregunta afirma que "Escribir código seguro para excepciones es muy difícil". Primero responderé a tus preguntas y luego responderé a la pregunta oculta detrás de ellas.

Respondiendo preguntas

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

Por supuesto que sí.

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

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

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

¿Puedes siquiera estar seguro de que lo es?

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

No puede estar 100% seguro de que su código sea seguro para excepciones. Pero luego, te esfuerzas por lograrlo, utilizando patrones conocidos y evitando antipatrones conocidos.

¿Conoce y/o utiliza realmente alternativas que funcionen?

No existen alternativas viables en C++ (es decir, deberá 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 de seguridad de excepción, primero debe saber qué nivel de seguridad de excepción tiene cada instrucción que escriba.

Por ejemplo, a newpuede generar una excepción, pero la asignación de un elemento integrado (por ejemplo, un int o un puntero) no fallará. Un swap nunca fallará (nunca escribas un swap de lanzamiento), un std::list::push_backcan throw...

Garantía de excepción

Lo primero que debes entender es que debes poder evaluar la garantía de excepción que ofrecen todas tus funciones:

1. none : Su código nunca debería ofrecer eso. Este código filtrará todo y se descompondrá en la primera excepción lanzada.
2. básico : esta es la garantía que debes ofrecer como mínimo, es decir, si se produce una excepción, no se filtran recursos y todos los objetos siguen completos.
3. fuerte : el procesamiento tendrá éxito o generará una excepción, pero si se produce, los datos estarán en el mismo estado que si el procesamiento no hubiera comenzado en absoluto (esto le da poder transaccional a C++)
4. nothrow/nofail : el procesamiento se realizará correctamente.

Ejemplo de código

El siguiente código parece C++ correcto, pero en realidad ofrece la garantía "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 luego, el orden de cada instrucción hace que toda la función sea "ninguna", porque si 3. arroja, x se filtrará.

Lo primero que debe hacer sería hacer que la función sea "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". No se filtrará nada y todos los objetos estarán en el estado correcto. Pero podríamos ofrecer más, es decir, una garantía sólida. Aquí es donde puede resultar costoso y es por eso que no todo el código C++ es sólido. 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 estableciendo Xsu valor correcto. Si alguna operación falla, tno se modifica, por lo que las operaciones 1 a 3 pueden considerarse "fuertes": si algo se produce, tno se modifica y Xno se filtrará porque pertenece al puntero inteligente.

Luego, creamos una copia t2de ty trabajamos en esta copia desde la operación 4 a la 7. Si algo falla, t2se modifica, pero tsigue siendo el original. Todavía ofrecemos la fuerte garantía.

Luego, intercambiamos ty t2. Las operaciones de intercambio no deben realizarse en C++, así que esperemos que el intercambio que usted escribió Tno lo sea (si no lo es, reescríbalo para que no lo sea).

Entonces, si llegamos al final de la función, todo tuvo éxito (no es necesario un tipo de retorno) y ttiene su valor exceptuado. Si falla, ttodavía conserva su valor original.

Ahora bien, ofrecer una garantía sólida podría ser bastante costoso, así que no se esfuerce por ofrecer una garantía sólida a todo su código, pero si puede hacerlo sin costo (y la incorporación de C++ y otras optimizaciones podrían hacer que todo el código anterior no tenga costo) , entonces hacerlo. El usuario de la función te lo agradecerá.

Conclusión

Se necesita cierta costumbre para escribir código seguro para excepciones. Deberá evaluar la garantía que ofrece cada instrucción que utilizará y luego deberá evaluar la garantía que ofrece 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 no debería impedirle intentar escribir código seguro para excepciones.

Fallo normal versus error

¿Cómo puede un programador garantizar que una función sin fallas 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 se ofrecen mediante un 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 sensato se protege a sí mismo contra la posibilidad de que tenga un error. Escriba el código lo mejor que pueda y luego ofrezca la garantía suponiendo que esté libre de errores. Y si hay algún error, corríjalo.

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

Ultimas palabras

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

Por supuesto que es. Tener una función "sin lanzamiento/sin falla" sabiendo que la función no fallará es una gran ayuda. Lo mismo puede decirse de una función "fuerte", que le permite escribir código con semántica transaccional, como bases de datos, con funciones de confirmación/reversión, siendo la confirmación la ejecución normal del código y las excepciones que arrojan la reversión.

Entonces, lo "básico" es la mínima garantía que debes ofrecer. C++ es un lenguaje muy potente allí, con sus alcances que le permiten evitar fugas de recursos (algo que a un recolector de basura le resultaría difícil ofrecer para la base de datos, la conexión o los identificadores de archivos).

Así que, a mi modo de ver, merece la pena.

Editar 2010-01-29: Acerca del intercambio sin lanzamiento

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

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

De forma predeterminada, std::swapse realizarán copias y asignaciones que, para algunos objetos, pueden arrojarse. Por lo tanto, el intercambio predeterminado podría generarse, ya sea utilizado para sus clases o incluso para clases STL. En lo que respecta al estándar C++, la operación de intercambio para vector, dequey listno arrojará, mientras que podría hacerlo mapsi el functor de comparación puede arrojar en la construcción de copia (consulte El lenguaje de programación C++, edición especial, apéndice E, E.4.3 .Intercambio ).

Al observar la implementación del intercambio de vectores en Visual C++ 2008, el intercambio de vectores no se generará si los dos vectores tienen el mismo asignador (es decir, el caso normal), pero hará copias si tienen asignadores diferentes. Y así, supongo que podría fallar en este último caso.

Entonces, el texto original aún se mantiene: nunca escribas un intercambio de lanzamiento, pero debes recordar el comentario de nobar: asegúrate de que los objetos que estás intercambiando tengan un intercambio de no lanzamiento.

Editar 2011-11-06: Artículo interesante

Dave Abrahams , quien nos brindó las garantías básica/fuerte/sin lanzamiento , describió en un artículo su experiencia sobre cómo hacer que la excepción STL sea segura:

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

Mire el séptimo punto (Pruebas automatizadas para seguridad de excepciones), donde se basa en pruebas unitarias automatizadas para asegurarse de que se prueben todos los casos. Supongo que esta parte es una excelente respuesta a la pregunta del autor "¿ Puedes estar seguro de que así es? ".

Editar 2013-05-31: Comentario de dionadar

t.integer += 1;no tiene la garantía de que no se producirá un desbordamiento, NO es una excepción segura y, de hecho, técnicamente puede invocar UB. (El desbordamiento firmado es 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 no está definido".) Tenga en cuenta que unsigned Los números enteros no se desbordan, pero realizan 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 número entero ya está en su valor máximo (usando std::numeric_limits<T>::max()) antes de realizar la suma.

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

Corregí el código teniendo en cuenta el comentario de Dionadar.

Dec 05 '2009 22:12 paercebal