| INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO |

Introducción | Contenido | Bibliografía

Introducción
Contenido
UNIDAD I
UNIDAD II
UNIDAD III
UNIDAD IV
UNIDAD V
UNIDAD VI
UNIDAD VII
UNIDAD VIII Introducción 8.1 Planteamiento del problema 8.2 Téncnicas básicas de detección de errores 8.3 Agregando símbolos de error
UNIDAD IX
PROBLEMARIO
Bibliografía

8.3 Agregando símbolos de error

> Se entiende por mensajes o diagnósticos de error o aquellas cadenas de caracteres que emite el compilador con el fin de notificar al usuario la presencia de un error o contingencia ocurridos durante el propio proceso de traducción.
> Los diagnósticos deberán estar por tanto lo más directamente relacionados con el error que pretendan denotar.
> Un compilador que emita como toda respuesta al final del proceso:

> “EXISTEN 5 ERRORES EN EL PROGRAMA”

> No podrá ser de una gran ayuda para el programador quien seguramente terminará por decidir utilizar otro lenguaje de programación que le preste mayores satisfacciones y que se más explícito.

> Horning describió algunas de las características que deberían poseer tales mensajes:

> 1. Deben estar expresados en términos del usuario y del programador y no en términos del propio compilador. Un diagnóstico como:

> “HASING NO COMPLETADO PARA EL TOKEN DERIVADA”

> Sería sin duda para el usuario mucho más claro si estuviera dispuesto como:

> “IDENTIFICADOR DERIVADA NO DECLARADO”

> 2. Deben ser lo más específicos y localizados posible. El diagnóstico debe apuntar con la mayor de las proximidades al lugar exacto de la aparición de error. Sea el conjunto de instrucciones PL/I:

> 210 IF A > B THEN DO; A=A+1;
> 220 B=B-1;
> 230 ELSE DO; A=A(1;
> 240 B=B+1;

> Si el compilador generara el diagnóstico:

> “OPERADOR MAL SITUADO EN BLOQUE-DO”

> El usuario tardaría un cierto tiempo en localizar la sentencia de asignación anómala.

> Si, por el contrario, este mensaje estuviera mejor orientado:

> “LINEA 230: OPERADOR MAL SITUADO EN BLOQUE-DO”

> Aun no variando el contenido semántico del mismo su localización en el texto fuente sería más rápida lo que daría lugar a menos posibilidades de falsas interpretaciones.

> 3. Deberían ser completos en cuanto a texto y perfectamente legibles. Una excesiva compactación o abreviación del diagnóstico perjudica notablemente la labor de depuración de un programa. Este sería el caso para el ejemplo anterior:

> “LINEA 230: OP:ERROR”

> 4. No estará de más, después de todo lo anterior, que estos diagnósticos gocen de una cierta amabilidad en su planteamiento. Un mensaje como el siguiente:

> “EXISTEN 25 ERRORES IRRECUPERABLES: CODIGO OBJETO NO GENERADO”

> Será sin duda menos traumático que los siguientes mensajes:

> “DEMASIADOS ERRORES FATALES: PROGRAMA DEGENERADO”

> “¿HA LEIDO UD. EL MANUAL DE PRGRAMACION?”

> Se debe establecer una solución de compromiso entre el tratamiento de los diagnósticos y su utilidad. No deben escatimarse pequeños esfuerzos de claridad, comprensión en aras de una simplicidad que de hecho resulta ser poco práctica después de todo.

> La localización del error es absolutamente fundamental para el usuario. Todos los compiladores de lenguajes de uso general señalan en el propio diagnóstico la línea donde ha sido hallada la contingencia. Algunos de ellos, además, son capaces de marcar con un distintivo especial la columna comienzo del error.

> En PASCAL, por ejemplo, la instrucción:

> If A > B then begin A:
> If A>B then begin A:=(B+C/D;E:=2;
> ↑ error 36

> Donde también se le puede incluir el comentario, para aclarar el error. Como se muestra a continuación:

> “36: SE HA OMITIDO UN PARENTESIS DERECHO”

> Las líneas que han sido objeto de diagnóstico suelen generalmente ser marcadas en uno cualquiera de sus márgenes de modo que se facilite la localización visual de la contingencia por parte del usuario.

> Respecto de la localización de los diagnósticos, estos suelen incluirse o bien al final del texto fuente o bien sucediendo a cada instrucción errónea. Los diseñadores de compiladores para firmas comerciales específicas mantienen a este respecto actitudes dispares en uno u otro sentido.

> No todos los errores encontrados durante la compilación de un texto fuente poseen el mismo grado de importancia.

> Algunos permiten que se prosiga en el proceso de generación de código objeto y otros, por su gravedad, suprimen tal salida. Es frecuente encontrar compiladores que señalan cada uno de sus diagnósticos con un identificador de su gravedad relativa. Así, por ejemplo el COBOL ANSI distingue los mensajes entre: WARNING o de aviso, MINOR para los que continua generando código ensamblador, SERIOUS en varios grados de actitud y FATAL para los que se suprime la salida objeto.

> Atrás Siguiente

##### Introducción / Contenido / Unidad I / Unidad II / Unidad III / Unidad IV / Unidad V / Unidad VI / Unidad VII / Unidad VIII / Unidad IX / Problemario / Bibliografía

##### Inicio

##### Créditos

José Sánchez Juárez, Andrés Ortigoza Campos, Fabiola Ocampo Botello