En el mundo actual, Código de error es un tema de constante debate e interés para un amplio espectro de personas. Desde su impacto en la sociedad hasta su relevancia en la cultura popular, Código de error ha logrado captar la atención de personas de todas las edades, géneros y profesiones. A lo largo de la historia, Código de error ha sido objeto de estudio, análisis y discusión, lo que ha llevado a un mayor entendimiento de sus implicaciones y repercusiones en diferentes ámbitos. En este artículo, exploraremos la importancia de Código de error y cómo ha evolucionado a lo largo del tiempo, así como su influencia en el mundo moderno.
En programación, los códigos de error son mensajes numerados que corresponden a errores en una aplicación específica. Se usan a menudo para identificar fallos de hardware, software o una entrada de datos incorrecta del usuario, en lenguajes de programación que carecen de manejo de excepciones, aunque a veces se usan conjuntamente a ellas. Los códigos de error no deben confundirse con los valores de retorno, aunque ambos se usen conjuntamente en el manejo de errores. Algunos de los códigos de error más severos visibles al usuario son los códigos de error en la pantalla azul de la muerte de Windows.
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.
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:
Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.
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.