Ayudas a la compilación

Hay tres tipos de ayuda para el análisis y corrección de bases de datos:

• la ayuda al análisis en realidad es ofrecida por el archivo de símbolos. Esta tabla le permite encontrar más rápidamente sus variables. Esta es una herramienta valiosa para la interpretación de errores reportados por el compilador.
• la ayuda a la corrección es ofrecida por el archivo de errores que puede utilizar como archivo de texto.
• la ayuda de ejecución o control de ejecución ofrece una herramienta adicional de control para monitorear la coherencia y la fiabilidad de sus aplicaciones.

Nota: también se ofrece una asistencia significativa en la declaración de variables por los métodos compiler automáticos, ver Declarar tipos.

El archivo de símbolos es un documento de tipo texto cuyo largo depende del tamaño de sus bases. Por defecto, este archivo no se genera en el momento de la compilación. Para hacerlo, debe seleccionar la opción correspondiente en las Preferencias de la aplicación (ver Opciones de compilación). Cuando se genera, el archivo se ubica en la carpeta que contiene la estructura de la base y se llama NombreBase.symbols.txt. 

El archivo de símbolos se presenta como se ve a continuación cuando se abre utilizando un editor de texto:

El encabezado muestra el nombre de la base, la fecha y la hora de creación del documento. El documento está dividido en cuatro partes:

• Lista de variables interproceso.
• Lista de variables proceso.
• Lista de variables locales, en su método.
• Lista completa de los métodos de proyecto y de los métodos de base con sus parámetros, si aplica.

Estas dos listas están divididas en cuatro columnas:

• La primera columna contiene los nombres de las variables de proceso e interproceso y arrays utilizadas en su base. Estas variables están en orden alfabético.
• La segunda columna contiene el tipo de la variable. Los tipos son determinados una directiva de compilación o por el compilador en función del uso de la variable. Si el tipo de una variable no puede determinarse, la columna queda vacía.
• La tercera columna contiene el número de dimensiones del array, si la variable es un array.
• La cuarta columna contiene la referencia al contexto en la cual el compilador estableció el tipo de la variable. Si la variable se utiliza en varios contextos, sólo el contexto mencionado es utilizado por el compilador para determinar su tipo.
  
  • Si la variable se encuentra en un método base, el nombre del método base es dado como si hubiera sido definido en 4D, precedido por (M)*.
  • Si la variable se encuentra en un método de proyecto, el método es identificado como si hubiera sido definido en 4D, precedido por (M).
  • Si la variable se encuentra en un trigger (método de tabla), el nombre de tabla dado, es precedido por (MT).
  • Si la variable se encuentra en un método de formulario, el nombre de formulario se da precedido por el nombre de tabla y de (FM).
  • Si la variable se encuentra en un método de objeto, el nombre del método de objeto dado, es precedido por el nombre del formulario, el nombre de la tabla y por (MO).
  • Si la variable es un objeto de un formulario y no aparece en ningún método de proyecto, método de formulario, trigger o método de objeto, el nombre del formulario en el cual aparece es dado, precedido por (F).
  Al final de cada lista, encuentra los tamaños de las variables de proceso e interproceso en bytes.

Nota: en el momento de la compilación, el compilador no puede determinar en cual proceso se utiliza una variable de proceso dada. Una variable de proceso puede tener un valor diferente en cada proceso. Por lo tanto, todas las variables de proceso se duplican sistemáticamente cada vez que se crea un nuevo proceso: es conveniente tener cuidado con la cantidad de memoria que van a ocupar. Igualmente, recuerde que el espacio para las variables de proceso no está relacionado con el tamaño de memoria para el proceso.

La lista de variables está organizada por método de base, método de proyecto, trigger (método de tabla), método de formulario y método de objeto, en el mismo orden que en 4D.

Esta lista está dividida en tres columnas:

• La primera columna contiene la lista de variables locales utilizadas en el método;
• La segunda columna contiene el tipo de la variable;
• La tercera columna contiene el número de dimensiones si la variable es un array.

Una lista completa de sus métodos base y proyecto se entrega al final del archivo con:

• su tipo (procedimiento o función devolviendo un valor)
• los tipos de sus parámetros y el resultado devuelto
• el número de llamadas
• la propiedad Hilo seguro o Hilo no seguro (ver Procesos 4D apropiativos)

Esta información se presenta en el siguiente formato:

Puede generar o no un archivo de errores durante la compilación utilizando una opción ubicada en las Propiedades de la base (ver Opciones de compilación). Cuando se genera, el archivo de errores se llama NombreDeLaBase_errors.xml y se crea junto al archivo de estructura de la base.

Aunque los errores son directamente accesibles vía la ventana del compilador, puede ser útil tener un archivo de errores que pueda transmitirse desde un equipo a otro, particularmente dentro del marco de varios desarrolladores diferentes trabajando juntos en un entorno cliente servidor. El archivo de errores se genera en formato XML con el fin de facilitar el análisis automático de su contenido. También autoriza la creación de interfaces personalizadas de presentación de errores.

La longitud del archivo de errores depende del número de errores y avisos emitidos por el compilador. Cuando se abre un archivo de errores utilizando un editor de texto, se ve de esta forma:

La estructura del archivo de errores es la siguiente:

• En la parte superior del archivo está la lista de errores y avisos, organizados por método y en el orden de su creación en 4D;
• En la sección ***Errores generales***, se agrupan todas las imposibilidades de declaración y las ambigüedades de identidad. Estos errores y avisos se listan utilizando el siguiente formato:
  
  • Primero, el número de línea en el método (0 indica errores generales);
  • Segundo, el atributo aviso indica si la anomalía detectada es un aviso (warning="true") o un error (warning="false");
  • Y tercero, un diagnostico que describe el error.
  Si su base de datos no presenta ningún error general, el archivo no tendrá una sección “Errores generales”.

Un archivo de errores puede contener tres tipos de mensajes:

• Errores asociados a una línea específica,
• Errores generales,
• Avisos.

Estos errores se muestran en contexto, la línea en la cual se encuentran, con una explicación. El compilador reporta este tipo de error cuando encuentra una expresión en la cual ve una inconsistencia relacionada con el tipo de dato o sintaxis.

En la ventana del compilador, haga doble clic en cada error detectado para abrir el método relacionado directamente en el editor de métodos 4D con la línea que contiene el error resaltado.

La lista de diagnósticos de errores de sintaxis /digitación se encuentra en la sección Mensajes de error del manual Lenguaje de 4D.

Estos son errores que no permiten compilar la base de datos. Hay dos casos en los cuales el compilador reporta un error general:

• El tipo de una variable de proceso no puede determinarse.
• Dos tipos diferentes de objetos tienen el mismo nombre.

Los errores generales se llaman así porque no pueden asociarse a ningún método en particular. En el primer caso, el compilador no puede realizar una declaración específica en cualquier parte de la base. En el segundo, no puede decidir si asociar un nombre dado con un objeto o con otro.

La lista de errores generales se encuentra en la sección Mensajes de error del manual Lenguaje de 4D.

Los avisos no son errores. Los avisos no impiden la compilación de la base; simplemente señalan errores potenciales de código.

En la ventana del compilador, los avisos aparecen en caracteres itálicos. Haga doble clic en cada aviso para abrir el método relacionado directamente en el editor de métodos 4D. La lista de avisos se encuentra en la sección Advertencias del manual Lenguaje 4D.

Es posible desactivar algunos avisos (ver Desactivación de avisos durante la compilación).

El control de ejecución se selecciona por defecto en las Propiedades de la base (ver Opciones de compilación). 

Mientras todas las otras opciones funcionan durante el proceso de compilación, el control de ejecución comienza cuando ejecuta una base compilada. Es decir, los mensajes de control de ejecución sólo aparecen mientras se está ejecutando su base de datos compilada.

El control de ejecución introduce un análisis adicional con respecto a la coherencia lógica y sintáctica que caracteriza normalmente un compilador. Durante el control de ejecución, el compilador hace la siguiente pregunta: “Considerando lo que ha solicitado, ¿Lo sorprenderá el resultado que obtenga?” El control de ejecución es un controlador “in situ”, que evalúa el estado de los objetos en la base en un momento dado.

Así es cómo funciona el control de ejecución. Imagine que declaró el array MiArray como tipo Texto. El número de elementos en MiArray puede variar dependiendo del método actual. Si quiere asignar el valor “Hola” al elemento 5 de MiArray, escribe:

Si MiArray tiene cinco elementos o más, todo está bien. La asignación se efectúa normalmente. Sin embargo, si MiArray tiene menos de cinco elementos en ese momento, su asignación no tiene sentido.

Esta situación no puede detectarse en compilación por la suposición de que los métodos se están ejecutando. El compilador no sabe la circunstancia en la cual este método se llama. Sólo el control de ejecución le permite monitorear que está pasando exactamente mientras su base está en uso. En el ejemplo anterior, el compilador mostraría un error de ejecución en 4D. Fácilmente se ve por que el control de ejecución es particularmente valioso cuando se procesan arrays, punteros y cadenas de caracteres.

Los mensajes enviados por el compilador cuando solicita control de ejecución se listan en la sección Mensajes de control de ejecución del manual Lenguaje de 4D.

Incluso cuando el control de ejecución se haya activado, en algunos casos usted preferiría que no se aplicara a ciertas partes confiables del código. Particularmente, en el caso de los bucles repetidos muchas veces y cuando se ejecuta la base compilada en equipos viejos, el control de ejecución puede hacer el proceso más lento. En la medida que tenga la certeza de que el código relacionado es confiable y no puede causar errores de sistema, puede desactivar localmente el control de ejecución.

Para hacerlo, debe enmarcar el código a excluir del control de ejecución con los comentarios //%R- y //%R+. El comentario //%R- desactiva el control de ejecución y //%R+ lo activa nuevamente:

Nota: este mecanismo sólo funciona si el control de ejecución está activo.

Imagine que nota anomalías cuando ejecuta sus bases. Antes de especular sobre las posibles causas de estos problemas, recuerde la ayuda que ofrece el compilador.

Las posibles anomalías que se pueden presentar:

• 4D muestra sus propios mensajes de error.
  Si es posible, corrija errores en su base de datos de acuerdo a las instrucciones de 4D. Si estas son muy generales, compile su base nuevamente, asegurándose de que la opción Control de ejecución esté activa. En la ubicación donde fue mostrado el mensaje de 4D, verá un mensaje más informativo del compilador.
• Sus bases de datos compiladas no funcionan exactamente como su base interpretada. Observe los mensajes de aviso.
• Las variables numéricas o alfanuméricas no devuelven los valores esperados. Verifique las opciones de asignación de tipo en las Preferencias y examine el archivo de símbolos para verificar que todas sus variables estén bien declaradas.
• Su base funciona normalmente en modo interpretado, pero en modo compilado ocurre una caída del sistema. Asegúrese de compilar la base utilizando la opción Control de ejecución y verifique si su base compilada está utilizando los mismos plug-ins que utilizó al momento de la compilación.