Aserción (informática)

Las aserciones suelen ser útiles para especificar programas y para razonar la corrección de los mismos.

Por ejemplo, el siguiente código contiene dos aserciones:

x := 5;
{x > 0}
x := x + 1
{x > 1}

x > 0 y x > 1, y las dos son ciertas en dichos puntos de la ejecución.

Otro ejemplo: una precondición — una aserción al comienzo de una sección de código — determina que se espera que el conjunto de sentencias que la siguen sean ejecutadas. Una postcondición — colocada al final — describe el estado que se espera alcanzar al final de la ejecución.

El ejemplo anterior utiliza la notación introducida por C. A. R. Hoare en su artículo de 1969 "An axiomatic basis for computer programming" ("Una base axiomática para la programación de ordenadores"). Como esta notación normalmente no es aceptada por los compiladores de los lenguajes actuales, los programadores suelen incluir aserciones mediante comentarios. A continuación se incluye un ejemplo en C:

x = 5;
/*
 {x > 0}
*/
x = x + 1;
/*
 {x > 1}
*/

Se han incluido las llaves para distinguir este uso de los comentarios de su uso habitual.

Varios lenguajes de programación modernos incluyen una sentencia de aserción, que no es más que una aserción que se comprueba en tiempo de ejecución. Si su evaluación resulta falsa, se produce un "error de aserción". La intención de estas sentencias de aserción es facilitar la depuración del programa, evitando que dicho fallo quede sin comprobar.

El uso de aserciones ayuda al programador en las tareas de diseño, desarrollo y razonamiento de un programa.

En lenguajes como Eiffel, las aserciones son parte del proceso de diseño, mientras que en otros, como C o Java, solamente son utilizadas para comprobar suposiciones en tiempo de ejecución.^{[cita requerida]}

 int total = contarUsuarios();
 if (total % 2 == 0)
 {
     // total es par
 } 
 else
 {
     // total es impar
     assert(total % 2 == 1);
 }

Las aserciones suelen ser implementadas de modo que puedan ser activadas o desactivadas, normalmente en el conjunto del programa. Sin embargo, los lenguajes que distinguen entre distintos tipos de aserciones – p.ej. pre y postcondiciones – suelen permitir activarlas o desactivarlas de forma independiente. Si las aserciones son desactivadas, no se comprueban en tiempo de ejecución. De esta forma el programador puede colocar aserciones en lugares donde en otro caso no tendría sentido ponerlas (p.ej., comprobar que no se accede a un array mediante índices fuera de rango). Puesto que las aserciones son en principio una herramienta de desarrollo, normalmente son desactivadas cuando el programa en cuestión es publicado. Por otra parte, como algunas versiones del programa pueden incluir aserciones y otras no, es primordial que su desactivación no modifique el comportamiento del programa. En otras palabras, las aserciones deben ser libres de efectos colaterales. Una alternativa en el caso de C o C++ es redefinir la macro assert para evaluar la expresión incluso cuando las aserciones están desactivadas.

La eliminación de las aserciones del código de producción es un proceso que se realiza de forma casi automática. Normalmente se realiza mediante compilación condicional, por ejemplo utilizando el preprocesador de C o C++ o pasando un parámetro de ejecución, como en Java. Algunas personas, sin embargo, se oponen a la eliminación de las aserciones basándose en una analogía que compara la ejecución con aserciones y sin ellas en la fase de desarrollo con la práctica de la natación en una piscina con la vigilancia de un socorrista para después nadar solo en el mar. Asimismo añaden que las aserciones también ayudan a desarrollar un programa a prueba de fallos.

Es importante establecer las semejanzas y diferencias entre las aserciones y las rutinas de control de errores. Las aserciones deberían ser utilizadas para documentar situaciones lógicamente imposibles y descubrir posibles errores de programación— si ese "imposible" ocurre, es que algo fundamental está claramente equivocado. Esto difiere del control de errores: la mayoría de las condiciones de error son posibles, aunque deberían ser muy poco probables en la práctica. El uso de aserciones como mecanismo general de control de errores suele ser algo desacertado: las aserciones no permiten al programa recuperarse de los errores, y un fallo de aserción suele suponer una terminación abrupta del programa. Asimismo las aserciones no suelen mostrar mensajes de error comprensibles por el usuario.

Considérese el siguiente ejemplo de uso de aserciones para manejar un error:

  int *ptr = malloc(sizeof(int) * 10);
  assert(ptr != NULL);
  // usar ptr

Aquí, el programador advierte que malloc puede devolver un puntero a NULL si no resulta posible realizar la asignación de memoria. Esto es posible: el sistema operativo no garantiza que cada llamada a malloc termine con éxito, y el programa debe estar preparado para manejar el error. Una aserción quizás no es la mejor elección en este caso, ya que un error causado por malloc no es lógicamente imposible — es una posibilidad legítima, aunque no es muy común que suceda. En este ejemplo, es cierto que la aserción resulta útil, aclarando que el programador ha decidido de forma deliberada no construir una rutina robusta de control de errores de asignación de memoria.

El programador también puede decidirse por una utilización mixta de aserciones y rutinas estándar de control de errores para un mismo problema. Esto es útil en situaciones donde el programador quiere recibir aviso inmediato del error, pero con la seguridad de que será manejado de forma correcta en situaciones reales de explotación del programa. En el ejemplo anterior, esto supondría añadir una rutina de control de errores, pero también habría que mantener la aserción para que el programador supiese del fallo de memoria durante el proceso de depuración. Esto permite al programador localizar errores de forma más sencilla, lo que a su vez hará que el usuario final pueda ejecutar el programa sin recibir mensajes de error innecesarios. Esta táctica solamente resulta útil cuando el error especificado no supone la terminación abrupta del programa o afecte a los datos que este maneja, sino que hará que el programa siga funcionando aunque sea más lentamente o de forma menos eficiente.

• Hoare, C. A. R. (2001). «Assertions: a personal perspective». research.microsoft.com. Archivado desde el original el 27 de diciembre de 2007.
• «Programming With Assertions in Java». java.sun.com. Archivado desde el original el 23 de febrero de 2008.
• «Using Assertions». java.sun.com. Artículo técnico.