Código de error

En lenguajes de programación sin manejo de excepciones (como el lenguaje de programación C), los códigos de error suelen almacenarse en variables globales con nombres como errno. Los códigos de error se identifican por un número, indicando cada uno un motivo de fallo. En una aplicación que use códigos de error, cada función suele tener un valor de retorno que indica que se produjo un fallo. A continuación se puede comprobar el valor disponible en la variable global para determinar el motivo que hizo fallar a la función. Por ejemplo, para indicar que falló la apertura de un archivo, una función suele establecer la variable global al código de error indicando el motivo del fallo y devolver un manipulador de fichero no válido, tal y como muestra el siguiente ejemplo:

/* intentamos abrir ''archivo'' para lectura*/
FILE *pFichero = fopen("archivo", "r"); /* if file cannot be opened, print error number and error string */
if(pFichero == NULL) 
printf("No se puede abrir el archivo, error nº %i, descripción: %s\n", errno, strerror(errno));

Puesto que los códigos de error acostumbran a ser variables globales, pueden ser leídas o escritas desde cualquier porción del programa. Como con cualquier variable global, esto es un problema en entornos multihilo, puesto que la variable puede ser modificada por más de un hilo, causando una condición de carrera. Para arreglar este problema, POSIX establece que errno debe ser una variable local al hilo^{[cita requerida]}.

POST <SOCURCE LANG"C">

Los códigos de error están lentamente desapareciendo según los nuevos lenguajes de programación orientados a objetos los reemplazan con excepciones. Las excepciones tienen la ventaja de ser tratadas con bloques específicos de código, separados del resto. Aunque se considera una mala práctica en la metodología que usa códigos de error y valores de retorno no comprobar los valores de retorno para mirar si la función falló, a menudo los programadores no comprueban si hubo algún error. Esta negligencia puede causar efectos no deseados, puesto que errores ignorados pueden causar fallos más severos posteriormente en el programa.

La implementación de las excepciones en cambio, al separar la gestión de errores de la lógica del programa, los hace más fáciles de escribir y entender, puesto que un único código de manejo de errores puede gestionar errores de múltiples funciones. La gestión de excepciones hace también el código más legible que las implementaciones con códigos de error, puesto que la gestión de excepciones no rompe la lógica del programa con múltiples comprobaciones de errores.

Si se intenta correr un programa bastante antiguo en sistemas con una versión reciente de libc, puede encontrarse con las siguientes situaciones dependiendo de la versión:

• El programa funciona pero genera un warning:

Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.

• El programa no funciona, dando el error

symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

errno está definido por el estándar ISO C como un lvalue modificable de tipo entero, y no debe declararse explícitamente. Era común en C tradicional declarar errno manualmente (extern int errno;) en vez de incluir <errno.h>. Esto ya no funciona en las últimas versiones de libc. En tales situaciones, hay que modificar el código fuente para reemplazar todos los extern int errno; con el include #include <errno.h>. No obstante, en versiones muy antiguas de sistemas UNIX, puede no estar disponible <errno.h> y necesitarse la declaración.

• Last Error
• Abortar (informática)
• Programación Orientada a Aspectos
• Error de software
• Análisis estático de programas
• Estado de salida

• "Errors: errno in UNIX programs" por Chris Herborth
• "Exception Handling in C without C++" por Tom Schotland y Peter Petersen
• "Error codes or Exceptions? Why is Reliable Software so Hard?" por Damien Katz
• Funciones de manejo de errores de Windows