Extensión de macro Assert () para implementar un manejo mínimo de errores

"Señor, se me ocurrió una defensa del dragón". ¡Ya no nos tiene miedo! Se activa por el aleteo de las alas de un dragón y enciende una sirena ruidosa para que todos puedan escuchar al dragón acercarse.
"¿Esta defensa hace algo más?"
"No, ¿por qué?" ¡Seremos advertidos!
"Sí ... Comido por las sirenas aullando ... Y sin embargo ... ¿recordarnos cuándo hemos planeado interrupciones? ...

Descripción del problema

Este método no pretende el concepto de manejo de errores en proyectos complejos y complejos. Más bien, es un ejemplo de lo que se puede hacer con medios mínimos.

Una buena norma es suponer que no se debe activar ninguna aserción () durante la ejecución del programa. Y si al menos una afirmación () funcionó al probar la aplicación, entonces debe enviar este error al desarrollador. Pero, ¿qué pasa si la aplicación no se prueba completamente? ¿Y afirmar () funcionará para el cliente? ¿Enviar error al desarrollador? ¿Abortar un programa? En realidad, esta será la versión de lanzamiento de la aplicación y la aserción estándar () simplemente estará deshabilitada. La pregunta también surge con la contradicción interna del sistema: debería haber una gran cantidad de afirmación () para facilitar la detección de errores, pero debería haber menos afirmación () para interrumpir menos al usuario y su trabajo con la aplicación. Especialmente no me gustaría "caer" si cuántas personas usan la aplicación dependen de la estabilidad del trabajo y si afirmar () es esencialmente insignificante (requiere corrección, pero permite, por ejemplo, continuar trabajando con bastante éxito).

Tales consideraciones conducen a la necesidad de refinar afirmar () c / c ++. Y defina sus propias macros que amplíen la funcionalidad del aserción estándar (), pero agregando un manejo mínimo de errores. Que tales macros sean.

VERIFY_EXIT (condición);
VERIFY_RETURN (condición, valor de retorno);
VERIFY_THROW (condición, excepción);
VERIFY_DO (condición) {/ * fail block * /};

(Estas macros también se pueden llamar de manera diferente. Por ejemplo, VERIFY_OR_EXIT (), VERIFY_OR_RETURN (), VERIFY_OR_THROW (), VERIFY_OR_DO (). O viceversa en una versión más corta).

Estas macros, en primer lugar, tienen una implementación tanto para la versión de depuración de la compilación como para la versión de lanzamiento. Eso les permite tener un comportamiento en la versión de lanzamiento del programa. Es decir realizar acciones no solo durante las pruebas, sino también con el usuario.

Descripción macro

(La descripción de las macros es aproximada, su otro diseño también es posible).

1) VERIFY_EXIT (condición);

Comprueba la condición de condición y, si es falsa, llama a la aserción estándar () (versión de depuración) y también sale de la función actual (versiones de depuración y liberación).

2) VERIFY_RETURN (condición, valor de retorno);

Comprueba la condición de condición y, si es falsa, llama a la aserción estándar () (versión de depuración), y también sale de la función actual devolviendo ReturnValue (versiones de depuración y liberación).

3) VERIFY_THROW (condición, excepción);

Comprueba la condición de condición y, si es falsa, llama a la aserción estándar () (versión de depuración) y también genera una excepción (versiones de depuración y liberación).

4) VERIFY_DO (condición) {/ * fail block * /};

Comprueba la condición de condición y, si es falsa, llama a la aserción estándar () (versión de depuración), y también realiza un bloqueo fallido o una operación que sigue inmediatamente a la macro (versiones de depuración y liberación).

Para todas las macros es importante:

• En todos los casos, la Condición debe ser verdadera para "pasar" la macro y falsa para activar la ruta de manejo mínimo de errores.
• Cada una de las macros implementa algún método mínimo de manejo de errores. Esto es necesario para implementar el comportamiento en caso de errores que no se detectaron durante la prueba, pero ocurrieron en el usuario. Dependiendo de la implementación, puede informar al desarrollador sobre un error que ocurrió en el cliente, pero también cada implementación proporciona una forma mínima de recuperarse de un error.

Patrones de uso macro

Por supuesto, lo más interesante es que los superhombres entropía (héroes de la reducción de errores en los programas) son el uso de estas macros.

1) Condiciones previas y posteriores.

El primer caso de uso es pre y post condiciones. Permítame recordarle que las condiciones previas verifican el estado del programa (argumentos de entrada, estado del objeto, variables utilizadas) para cumplir con los requisitos necesarios del fragmento de código ejecutado. Las condiciones de publicación (son menos comunes en los programas) están destinadas a verificar que hemos logrado el resultado deseado y que el estado de los objetos sigue siendo válido para el fragmento de código actual.

El uso de las macros propuestas es sencillo: asignamos cada verificación en una macro separada. Seleccionamos macros en función del manejo de errores que necesitamos. (VERIFY_EXIT () - error al procesar con la salida de esta función, VERIFY_RETURN () - error al procesar con la devolución de un valor, VERRIFY_THROW () - error al procesar con una excepción, etc.)

También puede agregar o usar la macro VERIFICAR (), que no hará ningún manejo de errores. Esto puede ser útil, por ejemplo, en condiciones de publicación al final de una función.

Estas macros son completamente autosuficientes si utiliza los principios del código puro y asigna suficientes funciones para implementar acciones atómicas. Cada función puede verificar el estado de un objeto, argumentos de entrada, etc. para llevar a cabo su acción atómica.

2) Semántica de una transacción.

Además, estas macros se pueden usar para implementar código con semántica de transacciones. Dicha semántica se entiende como: 1) preparación gradual para una operación con verificación de los resultados de cada una de las etapas de preparación; 2) la ejecución de la acción solo si todas las etapas de preparación fueron exitosas; 3) negativa a cumplir, si no se cumplen algunas condiciones en la etapa de preparación (con un posible retroceso del cumplimiento).

3) Diseño del código, teniendo en cuenta una posible extensión.

Esto es especialmente cierto para las bibliotecas y el código general, que inicialmente pueden desarrollarse dentro del contexto de una sola condición de ejecución, y luego pueden comenzar a usarse con otras condiciones (comenzar a usarse de manera diferente). En este caso, estas macros pueden describir los "límites" de la funcionalidad del código. Determine qué fue visto inicialmente como un error y qué fue exitoso. (Este enfoque está cerca de las condiciones pre post post clásicas). Por supuesto, escribo los "bordes" entre comillas, porque estos límites pueden revisarse, pero es importante determinar (o más bien transmitir a los futuros desarrolladores) el conocimiento de los límites aceptables del diseño del código.

Implementación macro

Supongo que la mayoría de los desarrolladores de nivel medio no tendrán problemas para implementar estas macros. Pero si necesita información, dedicaré algunos puntos importantes.

Las macros deben ser representables como una sola declaración. ¿Qué se puede hacer con do {} while (false) construcciones o similares. Por ejemplo, así:

#define VERFY_EXIT(cond) \ do{bool _= (bool)(cond); assert(_); if(!_) {return;}} while(false) \ /*end macro VERIFY_EXIT()*/ 

Entonces puedes escribir el siguiente código:

 if(a > 0) VERIFY_EXIT(a%2==0); 

Por supuesto, esta es solo una de las posibilidades de implementación. Puede implementar macros de otras maneras.

PD: ¡Batalla exitosa con entropía, superhombres!