Corrección de errores en AS3: Introducción

() translation by (you can also view the original English article)

En este tutorial, describiré parte de la información básica que necesita para depurar sus aplicaciones Flash. Encontrar y resolver errores en el código ActionScript no es una tarea fácil, por lo que en realidad se trata solo del primer artículo de una serie. En esta entrega, echaremos un vistazo a algunas de las cosas generales que puede hacer para ayudar a rastrear sus errores.

Los diferentes tipos de error

Primero, vamos a discutir qué es un error. Hay tres grandes categorías de errores, en ningún orden en particular:

Errores del compilador
Errores en tiempo de ejecución
Errores lógicos

Para diferenciar entre estos, es útil comprender el proceso de cómo se hace y se presenta un SWF.

En el proceso de creación de una película Flash (o aplicación, o como quiera llamarla), se escribe Código ActionScript y se crean activos gráficos que utiliza la película. Puede utilizar Flash Professional, Flash Builder y Flex Framework, o un editor e IDE de terceros como FlashDevelop o FDT. En todos los casos, el trabajo que realiza para crear la película se conoce como creación y el tiempo que dedica a hacerlo se conoce como tiempo de autor.

En algún momento, querrá ver las cosas que usted autor presentó como lo harían con el usuario final. Sin embargo, para poder ver esto, los activos de tiempo de autor (ActionScript, dibujos, imágenes, fuentes y texto, etc.) deben compilarse en el archivo SWF que ve el usuario final. Al presionar "Publicar" o "Probar película" en Flash, o "Ejecutar" en Flash Builder, está compilando el archivo SWF. El programa que esté utilizando para crear tomará sus activos de tiempo de autor y los compilará en un SWF. El tiempo que se tarda en hacerlo se denomina tiempo de compilación, como en, las cosas que suceden en esta fase se dice que suceden en tiempo de compilación.

Por último, puede ejecutar el archivo SWF en Flash Player y ver cómo se verá y funcionará cuando se presente. Esto sucede en el navegador con el complemento Flash Player, o directamente en Flash Professional cuando elige "Probar película", o como una aplicación de AIR que se ejecuta en el escritorio (o dispositivo móvil). No importa los detalles de cómo se presenta el SWF, ahora se está ejecutando y ahora estamos experimentando el tiempo de ejecución. Flash Player está ejecutando el archivo SWF y todo el código y los gráficos compilados están visibles.

Por lo general, todo esto sucede por usted; si utiliza Flash Professional, al elegir "Probar película" se compilará el archivo SWF y, a continuación, se ejecutará en su propio Flash Player. Si utiliza Flash Builder, al elegir "Ejecutar" se compilará el archivo SWF y, a continuación, se iniciará en un navegador. Este proceso de tres etapas es generalmente algo en lo que no piensas, por lo que me tomo el tiempo para discutirlo en detalle.

Ahora, sobre los errores, y cómo se relacionan con estas etapas.

Los errores del compilador son errores en el código que aparecen en tiempo de compilación. Hay algo tan fundamentalmente incorrecto con su código que el compilador se detiene en seco y dice: "Vaya, si continuamos, su SWF se arruinará seriamente. No puedo hacerlo. Simplemente no puedo". Bueno, ok, normalmente no es tan melodramático, pero se rescatará a la primera señal de problemas y se asegurará de que no se le dé la satisfacción de ver su SWF ejecutarse antes de solucionar los problemas.

Por lo general, se trata de errores de sintaxis, como llaves que faltan o que coinciden incorrectamente, o bien coincidencias incorrectas de tipo; cosas que una máquina puede mirar y saber que están mal. Se trata de errores que verá en el panel Errores del compilador de Flash Professional.

Panel Errores del compilador

Los errores en tiempo de ejecución son errores que se producen mientras se ejecuta el archivo SWF. En este caso, el código es sintácticamente correcto, ya que pasó por encima del compilador sin errores (lo sabemos porque el SWF se está ejecutando). Pero el código todavía tiene algún defecto que hizo que se ejecutara de una manera que a Flash Player no le gusta; o bien no sabe qué hacer con este resultado inesperado o está causando un error para hacerle saber que algo falló en tiempo de ejecución.

En estos casos, obtendrá un error oficial que detalla el problema y al menos una indicación general de dónde se produjo en el código. En Flash Professional, los verá cuando "Pruebe la película" en el panel Salida.

Un error en tiempo de ejecución en el panel de salida

Los errores lógicos son básicamente errores en la forma en que se controla el programa. Estos no son errores del compilador; el archivo SWF se compila y se ejecuta. Estos no son errores en tiempo de ejecución; Flash Player no ha lanzado un gran mensaje de error en la cara. Todo es técnicamente correcto y funciona, pero no están funcionando de la manera que usted quiere que lo hagan. Tal vez la cuadrícula que dispuso mediante programación tiene demasiadas columnas, o el total del carro de la compra no se está calculando correctamente, o una dirección de correo electrónico introducida por el usuario se valida como inaceptable cuando realmente lo es, o una secuencia de imágenes se muestra en el orden incorrecto.

Estos son los errores más difíciles de encontrar, ya que solo se pueden encontrar utilizando el swf de la forma en que estaba previsto que se utilizara y comparando los resultados reales estrechamente con lo que esperaba que sucediera. Y una vez encontrado, no recibe ningún mensaje de error útil que le dé una idea de lo que salió mal.

Even though we got this far without compiler or run-time error, something is wrong: we're missing a zero on the price.

A pesar de que llegamos hasta aquí sin error de compilador o en tiempo de ejecución, algo está mal: nos falta un cero en el precio.

Errores del compilador: Encontrar el problema

Los errores del compilador suelen ser los más fáciles de tratar. Esto se debe a que, por un lado, el compilador se detiene en seco y le informa sobre el error, y para dos, el propio error del compilador le indica lo que está mal, le indica el archivo y el número de línea, e incluso imprime esa línea de código para su referencia.

Los errores del compilador aparecen en el panel Errores del compilador, así que echemos un vistazo más de cerca a este elemento en particular del IDE de Flash:

El panel de errores del compilador, de nuevo

Como puede ver en el diagrama anotado anterior, cada error se muestra en su propia línea. Cada línea consta de la misma información básica. En la primera columna, obtendrá el nombre de archivo y el número de línea en el que se encontró el error. En el ejemplo anterior, el error se produce en un archivo de clase. Si escribió código directamente en el panel Script, obtendrá algo como "Escena 1, Capa 'Capa 1', Fotograma 1, Línea 1", que es lo mismo, solo para código no basado en archivos de texto.

Saber dónde se produce el error es útil, pero la segunda columna contiene información sobre por qué se produjo el error. El primer bit es el número de error, que es como un identificador. Cada tipo de error obtiene su propio número. Esto va seguido de una descripción textual del error. Ahora, para ser justos, Adobe tiene algunas descripciones de errores redactada de manera bastante obtusa, y en futuros artículos de esta serie, intentaremos descifrar algunas de las más comunes para que pueda lidiar con ellas de manera más efectiva. Hasta entonces, al menos podemos aprender que el número de error está asociado con la descripción del error. El texto de la descripción puede personalizarse para presentar cierta relevancia contextual, como el uso de la variable o el nombre de la función del código fuente, pero el error general está vinculado al número. Por ejemplo, el error 1067 es un error de coerción, independientemente de si se trata de una conversión de string a DisplayObject o de array a externalinterface.

Puede encontrar una lista completa de errores de Complier en esta página en la documentación de ActionScript de Adobe:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/compilerErrors.html

Algunos errores se dan explicaciones más exhaustivas en esta página.

Errores del compilador: Resolver el problema

Lo bueno de los errores del compilador es que son bastante fáciles de encontrar. No solo aparecen y le impiden ejecutar su SWF, sino que también puede acceder al código problemático muy fácilmente desde el panel Errores del compilador. Simplemente haga doble clic en cualquier error en el panel y el archivo de origen correspondiente se abrirá, con el cursor en la línea derecha. Ahora, si utiliza Flash Professional con un editor externo, se encontrará haciendo doble clic en la edición del archivo en Flash Professional. Esto puede ir en contra de sus razones para usar un editor externo, pero al menos la búsqueda de errores suele ser bastante rápida y puede hacerlo sin dolor. Incluso si utiliza CS5 con la estrecha integración de Flash Builder, al hacer doble clic en el error aparece el archivo en Flash Professional, no en Flash Builder. Pero Flash Builder tiene su propio panel de errores del compilador, que funciona de la misma manera.

The Flash Builder Compiler Errors panel, or the "Problems" panel

El panel Errores del compilador de Flash Builder o el panel "Problemas"

En este punto, es cuestión de ir a la línea de código especificada por el error y corregirlo.

Errores en tiempo de ejecución: Encontrar el problema

Una vez que obtenga los errores del compilador, su SWF podrá ejecutarse, pero en este punto puede toparse con errores en tiempo de ejecución. Estos suceden por cualquier número de razones , de nuevo, vamos a explorar estos más adelante en esta serie - pero por ahora, vamos a explorar la anatomía de un error en tiempo de ejecución. A continuación se muestra un error típico en tiempo de ejecución que se muestra mientras el archivo SWF se ejecuta desde "Probar película" en Flash Professional:

The Output panel displaying a run-time error

El panel Salida muestra un error en tiempo de ejecución

Potencialmente va a haber una gran cantidad de texto escupir en usted cuando aparece un error. Puede parecer un poco intimidante inicialmente, pero en realidad son solo dos secciones principales:

The two main sections of the run-time error

Las dos secciones principales del error en tiempo de ejecución

Como se anotó anteriormente, el primer bit del error es la descripción de lo que sucedió. Al igual que los errores en tiempo de compilación, cada tipo de error en tiempo de ejecución tiene un número de error, que está asociado a una breve descripción textual. La descripción incluye un tipo de error, así como una oración de habla nerd. El tipo de error puede ser útil para tener una idea amplia de lo que está sucediendo, pero la descripción es lo que realmente le indica el problema. Echaremos un vistazo a un ejemplo en breve.

La segunda pieza principal es cualquier texto que sigue al primer bit, llamado la pista de pila o pila de llamadas y profundizaremos en eso en el siguiente paso.

Al igual que los errores en tiempo de compilación, las descripciones textuales dejan un poco que desear. Sin embargo, una vez que tenga una idea de lo que significan algunos de los errores más vistos, tendrá una idea de lo que está mal y sabrá dónde buscar.

Aquí se documenta una lista completa de errores en tiempo de ejecución, algunos de los cuales tienen notas junto con ellos:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/runtimeErrors.html

Errores en tiempo de ejecución: Descripción del seguimiento de pila

Pasemos al segundo bit principal del error en tiempo de ejecución, el seguimiento de la pila. Puede variar en longitud en cualquier lugar de una línea a un número finito-pero-muy-grande de líneas. El propósito de este seguimiento de pila es notificarle en qué parte del código se produjo el error.

Cada línea del seguimiento de pila representa una ejecución de función única. La línea superior asigna un nombre a la función en la que se produjo realmente el error; contiene la línea de código que explotó todo. La segunda línea del seguimiento de pila asigna un nombre a la función que llamó a la función que produjo el error. La tercera línea nombra la función que llamó a la función que llamó a la función en la que se produjo el error. y... te haces a la idea. Pero vamos a ilustrarlo de manera más práctica. En el código siguiente, la tercera función producirá un error en tiempo de ejecución al intentar agregar "nada" a la lista de presentación. Sin embargo, no lo llamamos de inmediato; comenzamos las cosas llamando a la primera función, que llama a la segunda función, que a su vez finalmente llama a la tercera función:

first();
function first():void {
    second();
}
function second():void {
    third();
}
function third():void {
    var s:Sprite;
    addChild(s);
}

Si pega ese código en el panel Script de un nuevo archivo Flash y lo ejecuta, verá el siguiente error:

TypeError: Error #2007: Parameter child must be non-null.
    at flash.display::DisplayObjectContainer/addChild()
    at Untitled_fla::MainTimeline/third()
    at Untitled_fla::MainTimeline/second()
    at Untitled_fla::MainTimeline/first()
    at Untitled_fla::MainTimeline/frame1()

Ahora, sabemos que el error se debió al envío de una variable Sprite no inicializada a addChild. La función que realmente produjo el error (ese es el término técnico; cuando se produce un error, significa que el error fue lanzado por una línea de código específica. Me gusta pensar que es similar a lanzar una rabieta) es el método addChild, por lo que está en la parte superior de la lista. Las siguientes tres líneas son las funciones que escribimos, enumeradas más recientes primero. Finaliza (o comienza, dependiendo de cómo lo mires) con una llamada a frame1 en la línea de tiempo principal. Este es solo el método que inicia el SWF. Si tuviera una clase de documento configurada, lo vería en su lugar. Dado que este ejemplo solo usa un script en el primer fotograma, obtenemos frame1.

El punto es que llamar a frame1 en última instancia condujo a una llamada errónea a addChild, y puede seguir esa ruta de acceso de la lógica leyendo el seguimiento de pila.

Esta lista completa de llamadas de función puede parecer que es solo un lío de información que no necesita, pero hay varias veces en las que puede ayudarlo a reducir su error. Si el error sólo se produce en la función dada a veces, es posible que pueda averiguar el problema mediante el seguimiento de los pasos necesarios para llegar a la función. Por ejemplo, si hubiera un poco más de interacción en las funciones:

var s:Sprite = new Sprite();

first();
function first():void {
    second();
}
function second():void {
    s = null;
    third();
}
function third():void {
    addChild(s);
}

La tercera función podría ser el infractor más inmediato, pero un examen detallado revelaría que la segunda función era la que realmente hacía de s un valor nulo.

Errores en tiempo de ejecución: Flash Debug Player

Una herramienta esencial para el desarrollador de Flash es la versión de depuración de Flash Player. Si aún no lo tienes instalado, debes detener lo que estás haciendo (leyendo este artículo) e ir a descargarlo ahora mismo. Usted tendrá que reiniciar el navegador, ya que es una reinstalación de Flash Player, así que marque esta página primero!

Vaya aquí para descargar el instalador apropiado:

http://www.adobe.com/support/flashplayer/downloads.html

(Usuarios de Chrome: lee esta nota de soporte para averiguar cómo anular flash player integrado de Chrome).

Una vez que reinicie su navegador, no notará mucho diferente de inmediato. Pero pruébalo en este SWF a continuación. En primer lugar, debería ver algún texto que indique su versión actual de Flash Player, incluido si es la versión de depuración o no. Pero haga clic en el botón grande, que está conectado a una función que en última instancia arrojará un error. Si prueba esto sin el reproductor de depuración, no verá que suceda nada; el error se producirá, pero se producirá un error de forma silenciosa. Sin embargo, si lo intenta con el reproductor de depuración, obtendrá un mensaje de error bastante molesto y difícil de pasar por alto:

Si se siente demasiado perezoso para instalar realmente el reproductor de depuración, o simplemente desea verificar que lo hizo bien, el error que ve debería tener un aspecto similar al siguiente:

The error window displayed when the debug player is installed.

La ventana de error que se muestra cuando se instala el reproductor de depuración.

Claramente, tener el reproductor de depuración instalado es extremadamente útil para ser alertado de errores mientras prueba sus ARCHIVOS SWF en el navegador. Como puede imaginar (o ya ha notado), un SWF que se ejecuta bien desde el IDE de Flash puede encontrar algo de lo que quejarse cuando se coloca en un entorno diferente, como su servidor web. Imagine que el archivo SWF depende de un archivo XML para cargarlo, pero si la ruta de acceso a ese archivo XML se resuelve incorrectamente en el servidor Web en comparación con el entorno de desarrollo local, se producirá un error de carga. Sin duda sería útil saber sobre esto tan pronto como suceda, en lugar de ser presentado con un SWF que no funciona y no hay pistas.

La desventaja del reproductor de depuración es que es más bien todo o nada; no puede no depurar sitios que no está desarrollando. Es decir, si solo está navegando por la web, eventualmente desencadenará algunos errores de tiempo de ejecución en otros ARCHIVOS SWF. Es molesto, y le da una idea de lo poco que algunos desarrolladores prestan atención a su proceso de prueba.

Como consejo adicional, puede saber fácilmente si tiene la versión normal o la versión de depuración del reproductor simplemente haciendo clic con el botón derecho en cualquier SWF y buscando las opciones "Mostrar regiones de redibujo" y "Depurador" en él:

The Flash Player context menu, when invoked from a debug player

El menú contextual de Flash Player, cuando se invoca desde un reproductor de depuración

Errores en tiempo de ejecución: Permitir la depuración

Independientemente de si está viendo o no errores en tiempo de ejecución en el IDE o en el explorador, un error solo es informativo hasta cierto punto. Si tiene un error que se produce en algún lugar de una función, pero esa función tiene una longitud de 20 líneas, puede tener un poco de problemas para determinar dónde está la línea de código incorrecta.

Hay dos técnicas que tienen los mismos resultados, en que se proporciona más información en forma de la línea de código en cuestión para cada llamada de función.

La primera técnica es más inmediata: en lugar de presionar Comando-Retorno/Control-Entrar para probar su película, presione Comando-Shift-Return/Control-Shift-Enter para depurar su película. De este modo, se inicia el archivo SWF en el depurador de Flash Player, con una sesión de depuración iniciada. Cuando se desencadena un error en tiempo de ejecución, se recuperará al IDE de Flash (que debería reconfigurarse en un espacio de trabajo de depuración) y verá un poco más de información en el seguimiento de la pila (tenga en cuenta específicamente los números de línea agregados a la salida siguiente):

Attempting to launch and connect to Player using URL /Users/dru/Library/Caches/TemporaryItems/Untitled-1.swf
[SWF] Users:dru:Library:Caches:TemporaryItems:Untitled-1.swf - 2291 bytes after decompression
TypeError: Error #2007: Parameter child must be non-null.
    at flash.display::DisplayObjectContainer/addChild()
    at Untitled_fla::MainTimeline/third()[Untitled_fla.MainTimeline::frame1:12]
    at Untitled_fla::MainTimeline/second()[Untitled_fla.MainTimeline::frame1:8]
    at Untitled_fla::MainTimeline/first()[Untitled_fla.MainTimeline::frame1:5]
    at Untitled_fla::MainTimeline/frame1()[Untitled_fla.MainTimeline::frame1:3]
Cannot display source code at this location.

Como ventaja adicional, si es posible Flash abrirá el archivo responsable de lanzar el error y apuntará a la línea en cuestión. Muchos errores integrados se producen realmente dentro de las clases integradas, por lo que no es posible mostrar ese código. Pero si desea verlo en acción, pruebe el siguiente código:

function doIt():void {
    trace("do it");
}

var functionRef:Function = doIt;

functionRef("argument not expected");

... y ejecútelo a través de Debug Movie. Línea 7 debe ser llamado hacia fuera.

Sin embargo, como hemos discutido, a veces es necesario realizar pruebas en un servidor y a través de un explorador, y las funciones de depuración del IDE de Flash son menos útiles en ese sentido. Con el reproductor de depuración que instalamos en el último paso, hay una manera de obtener la información del número de línea incluida en la ventana de error en tiempo de ejecución. Esto es tan simple como habilitar una opción de publicación.

En el documento de Flash, elija File > Publish Settings... y luego haga clic en la pestaña Flash. Hacia la parte inferior, bajo el encabezado "Avanzado", verá una opción de casilla de verificación para Permitir depuración. Asegúrese de que esto esté habilitado y, a continuación, haga clic en "Aceptar".

The Permit Debugging option in the Flash Publish settings

La opción Permitir depuración en la configuración de publicación de Flash

Vuelva a publicar el archivo SWF y haga lo que tenga que hacer para ejecutarlo de nuevo en el navegador. Cuando ahora se produce un error en tiempo de ejecución, verá la misma información de número de línea.

Runtime error in the browser, with line numbers

Error de tiempo de ejecución en el explorador, con números de línea

No obtendrá la capacidad de saltar al código fuente, pero este truco de número de línea puede ahorrarle un montón de tiempo en el seguimiento de errores.

Sin embargo, tenga cuidado de activar Permitir depuración cuando esté listo para implementar el archivo SWF en el mundo. Flash necesita añadir información adicional al SWF para proporcionar los números de línea, y el tamaño de archivo resultante del SWF suele ser entre un 25 % y un 50 % superior al normal. Es una herramienta de depuración útil, pero no es algo que deba activar para todo en todas partes.

Errores en tiempo de ejecución: Inicie los suyos propios

He mencionado antes que es posible lanzar sus propios errores (y sus propias rabietas, pero sólo voy a describir cómo hacer el primero). Esto puede ser una técnica útil en la depuración. Si, por ejemplo, tiene la siguiente función:

1	function parseXML(xml:XML):void {
2	// xml parsing ensues...
3	}

Y esta función es parte integral de la funcionalidad del resto de la película (presumiblemente no podemos continuar con la pieza controlada por XML si el XML no se analiza), entonces podría estar en un giro desagradable de los eventos si el objeto XML que se pasa a la función un objeto nulo, o tal vez no se ajusta a la estructura que espera.

Por lo tanto, podría considerar, en esta importante función, configurar algunas comprobaciones y, si las comprobaciones fallan, arrojar algunos errores. Puede ser tan simple como esto:

function parseXML(xml:XML):void {
    if (xml == null) {
        throw new Error("The XML object passed in to parseXML cannot be null.")
    }
    // xml parsing ensues...
}

Estrictamente hablando, probablemente desee utilizar argumenterror en lugar de error antiguo, pero el resultado es esencialmente el mismo. Si ejecuta este código:

1	parseXML(null);

Verá un error útil:

El error en tiempo de ejecución

Además, puede prever que el XML podría no ser null, pero podría editarse de una manera que no coincida con las expectativas de la función de análisis. Si necesita que un nodo llamado <entries>se llene con nodos secundarios llamados <entry>, pero debido a un error humano, el archivo XML se veía así:

<content>
    <entries>
        <item name="one" />
        <item name="two" />
        <item name="three" />
    </entries>
</content>

Entonces el análisis no funcionaría. Usted podría protegerse contra esto:

function parseXML(xml:XML):void {
    if (xml == null) {
        throw new Error("The XML object passed in to parseXML cannot be null.")
    }
    // xml parsing begins... at some point:
    var entries:XMLList = xml.entries.entry;
    if (entries.length() == 0) {
        throw new Error("There were no entry nodes in the <entries> nodes.  "
            + "Instead, it looked like this:\n" + xml.entries.toXMLString());
    } else {
        // xml parsing ensues...
    }
}

Y debería obtener este error:

Otro error útil en tiempo de ejecución

Es posible que se guarde a sí mismo, o a otra persona, algún tiempo después de la línea cuando los archivos XML se editan incorrectamente.

Errores en tiempo de ejecución: obtener el seguimiento de pila sin un error

A veces, el seguimiento de pila es útil por sí mismo, incluso si no se ha producido ningún error. Por ejemplo, de vez en cuando me encuentro con un método que se llama más a menudo de lo que creo que debería. Si tan solo pudiera ver qué otros métodos lo están llamando, entonces podría encontrar de dónde viene la llamada adicional.

A primera vista, lanzar errores parecería una solución adecuada. Pero un error tiende a detener una película Flash en sus pistas. Si el primer error me proporciona un seguimiento de pila, podría evitar que la segunda llamada se produzca porque el primer error lo impidió. En estas situaciones, es bueno saber un poco más acerca de los objetos Error.

Lo más útil es el método getStackTrace, que devuelve el seguimiento de la pila tal como se presentaría si se iniciara el error. Lo bueno, sin embargo, es que no es necesario tirarlo para obtener esta información. Por lo tanto, si simplemente tiene curiosidad por ver el seguimiento de la pila sin producir errores, puede hacer algo como esto:

function whoCalledme():void {
    var e:Error = new Error();
    var stack:String = e.getStackTrace();
    trace(stack);
}

Si ve esto en el IDE de Flash, las diferencias entre esto y un error lanzado serán difíciles de detectar; ambos simplemente enviarán un montón de información al panel Salida. Podría considerar embellecer el rastro para que sea más fácil distinguir la diferencia. Sin embargo, si está probando en el navegador, este código no presentará la ventana de error, sino que simplemente escribirá en el registro de flash para su lectura (me estoy adelantando a mí mismo, el rastreo desde el navegador se cubre en unos pocos pasos).

Traza el diablos de todo

Hablando de seguimientos, cuando se trata de depuración, el seguimiento es la mejor herramienta que tiene disponible. Claro, Flash Professional y Flash Builder tienen depuradores, que le permiten establecer puntos de interrupción, recorrer el código e inspeccionar variables, pero honestamente, creo que la ruta más rápida entre el error y la recopilación de suficiente información para solucionarlo es un puñado de seguimientos colocados juiciosamente. Los seguimientos son útiles para depurar errores lógicos y en tiempo de ejecución, pero dado que tenemos herramientas disponibles para obtener información sobre los errores en tiempo de ejecución, los seguimientos pueden ser la primera línea de defensa contra los errores lógicos.

Si estoy depurando un error lógico, normalmente sé dónde centrarme. Lo que no funciona normalmente se localiza en una clase o dos y, por lo general, en un puñado de métodos y propiedades. Así que, dentro de las áreas problemáticas potenciales, yo rastreo el diablo de todo.

Más concretamente, tiendo a hacer lo siguiente:

Coloque un seguimiento como la primera instrucción dentro de una función o método, junto con una salida de cualquier parámetro, solo para asegurarse de que se llama a las funciones y los parámetros son lo que espero que sean.
Realice un seguimiento de cualquier variable o propiedad que se utilice en la función, al menos una vez. Si la propiedad está sujeta a cambios durante la función, coloque un seguimiento antes y después del posible cambio.
Realice un seguimiento de las instrucciones condicionales, solo para marcar a qué rama se obtiene.
Realice un seguimiento de todas las iteraciones de bucles, normalmente con cierta información sobre la iteración (como el número de índice y/o el objeto de la matriz relevante para esa iteración)
Si una variable es un objeto complejo, como un Sprite o un Sonido, trace varias propiedades del objeto

Como regla estilística, me parece inmensamente útil para asegurarse de que el rastro está etiquetado, también. Es decir, algo como esto:

1	trace("mySprite: " + mySprite);

De esta manera, después de haber agregado una docena de seguimientos al código, puede identificar el que dice null entre todos los demás seguimientos más fácilmente.

Además, es posible que incluso desee anteponer el nombre de la clase (y el método) en los seguimientos, solo para ayudar a identificar aún más el origen de cada seguimiento.

No hay reglas duras y rápidas para el rastreo, solo mi recomendación general de rastrear todo, incluso las cosas que crees que no necesitas, solo para estar seguro. En este punto, una pregunta a los lectores es apropiada: ¿en qué técnicas de rastreo confías? Siéntase libre de comenzar una guerra de llamas en los comentarios.

[Nota del editor: Por favor, no comience una guerra de llamas en los comentarios.]

Seguimiento: Seguimiento desde el explorador

Otra ventaja del reproductor de depuración (para Flash Developer, por supuesto) es la capacidad de ver sus rastros desde el navegador, por lo que puede probar y depurar un SWF de forma más eficaz en su hábitat natural.

Desafortunadamente, es necesario tomar medidas para habilitar este seguimiento, y no repetiré lo que se ha escrito en otra parte. Una búsqueda en "flash debug trace" arrojará muchos artículos de procedimientos, de los cuales mi favorito está actualmente en la parte superior de la lista en Google, un artículo detallado sobre yourpalmark.com que cubre varias versiones del reproductor en sistemas Mac, Windows y Linux.

Agregaré un consejo para los usuarios de Macintosh. La aplicación de consola se menciona de pasada en el artículo vinculado, pero no se explica realmente o, en mi opinión, se hace uso de correctamente. La consola se instala con Mac OS X y reside en la carpeta /Applications/Utilities. Es ideal para mostrar archivos de registro, que los seguimientos del reproductor de depuración son realmente. Es inteligente desplazarse hasta la parte inferior si ya estás en la parte inferior, pero no desplazarte si no lo estás. Es fácil filtrar y buscar en el registro, y me parece indispensable para el desarrollo de Flash.

The Mac's Console application in use for Flash traces

La aplicación de consola de Mac en uso para seguimientos flash

El truco, sin embargo, es que mientras que la consola puede abrir cualquier archivo de texto, sólo recuerda los archivos si están en las ubicaciones de archivos de registro estándar en su sistema, y si son archivos .log. Sin embargo, flash debug player sólo escribe trazas en un archivo denominado flashlog.txt, que se encuentra en una ubicación de archivo de registro no estándar. Hay un comando de terminal simple que puede emitir para crear un enlace simbólico en el lugar correcto:

1	ln -s ~/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt ~/Library/Logs/flashlog.log

Escribí más sobre este truco en el blog flash de mi empresa aquí: http://summitprojectsflashblog.wordpress.com/2008/12/17/leopards-console-and-flash-debug-player-traces/

El depurador de Flash

Como se ha mencionado anteriormente, Flash Professional y Flash Builder proporcionan entornos de depurador. Personalmente, los encuentro de utilidad limitada, ya que prefiero confiar en seguimientos y errores en tiempo de ejecución. Además, el uso eficaz del depurador depende de que se puedan establecer puntos de interrupción, lo que solo se puede hacer (fácilmente) en código abierto en Flash Professional o Flash Builder. Como una cuestión de preferencia personal, uso TextMate como mi editor de elección, lo que hace que establecer puntos de interrupción sea engorroso. Sería negligente, sin embargo, si no mencionara el depurador de Flash en un artículo sobre la depuración de Flash.

A continuación se muestra un recorrido rápido por las herramientas de depuración que obtiene con Flash Professional. Volvamos a nuestro ejemplo de producción de errores en tiempo de ejecución de anteriormente. Pegue este código en el panel de script de un archivo Flash:

var s:Sprite = new Sprite();

first();
function first():void {
    second();
}
function second():void {
    s = null;
    third();
}
function third():void {
    addChild(s);
}

Sin embargo, antes de presionar Depurar película, haga clic a la izquierda del número "5" en el panel Script.

La columna de puntos de interrupción

Aparecerá un punto rojo en la columna, lo que indica que se ha establecido un punto de interrupción. Para quitar un punto de interrupción, simplemente haga clic en él de nuevo. Con el punto de interrupción establecido en la línea 5 (donde se llama a second dentro de first), siga adelante y depure la película. Ahora, esperamos que el área de trabajo de depuración se haga cargo debido al error, pero si observa lo que está sucediendo, el error no ha ocurrido realmente (todavía). Hay una flecha amarilla que apunta a la línea 5, lo que indica que la ejecución del programa está en pausa en nuestro punto de interrupción. En este punto, tenemos la capacidad de recorrer el código una línea a la vez, y en el proceso inspeccionar el valor de las variables, ayudándonos a encontrar nuestro error.

Hemos llegado al punto de quiebre

Mueva su atención al panel Variables, en la esquina inferior derecha.

Panel Variables

Twiddle abra esta entrada, y verá una lista anidada de todas las propiedades que pertenecen a "this", que es la línea de tiempo principal de nuestro SWF. Desplázate hacia abajo y verás "s", nuestra variable Sprite. Es posible que deba ampliar el panel, pero la segunda columna debe tener un valor, como flash.display.Sprite, que indica que contiene un valor.

The Variables panel, with the s variable exposed

El panel Variables, con la variable s expuesta

Tenga en cuenta que este panel se puede utilizar para inspeccionar el valor actualmente en cualquier propiedad en el momento de la pausa de la película. También tenga en cuenta que mientras la película está en pausa, puede hacer doble clic en algunos de los campos de valor y escribir nuevos valores. Esto solo funcionará en valores primitivos como Cadenas y Números, pero es una técnica útil para saber.

Ahora, mueva los ojos hacia arriba al panel Consola de depuración. Aquí es donde podemos controlar la pausa y ejecución de nuestro código. En la parte superior del panel hay una serie de botones. Busque este:

El botón Paso a paso por 1

Haga clic en él una vez, y notará que la flecha amarilla avanzó de la línea 5 a la línea 7. Esto indica lo que ha sucedido; hemos ejecutado completamente la línea 5, que implica una llamada a la función declarada en la línea 7. El siguiente paso en nuestro programa es llamar a esa función. Compruebe nuestra variable s en el panel Variables. Todavía debe tener un valor Sprite.

Haga clic de nuevo en el botón Paso a paso por 1.Click the Step In button again. La flecha amarilla debe apuntar a la línea 8, donde establecemos s en null. Sin embargo, si vuelve a inspeccionar el panel Variables, seguirá teniendo un valor s. Esto se debe a que estamos en pausa en la línea 8, pero antes de que la línea 8 realmente se ejecuta.

Haga clic en el botón Paso a paso por 1 una vez más y, con la flecha amarilla ahora más allá de la línea 8, inspeccione la propiedad s en el panel Variables. Is ahora debe ser null. Si este ejemplo no fuera tan simple, ahora podríamos tener una revelación de que el código que acabamos de ejecutar es responsable de anular nuestra propiedad, lo que a su vez causa nuestro error.

En este punto, nos hemos convencido de que esta es la causa del error, por lo que no es necesario seguir recorriendo el código. Podemos presionar el botón verde Continuar, que reanudará la ejecución normal, y luego debería ver que se produce el error.

Envolviendo

Como decían en los años 80: ahora ya sabes, y saber es la mitad de la batalla. Ahora debe conocer algunas técnicas de depuración y tal vez aprendió por qué algunos errores aparecen en diferentes lugares.

Desafortunadamente, conocer los hechos de la depuración sigue siendo sólo la mitad de la batalla. La otra mitad es mucho más difícil de escribir en un tutorial. La otra mitad tiene más que ver con la experiencia y la intuición. Después de haber corregido cientos de errores, comienzas a tener una idea de lo que realmente se trata un error determinado. También es necesario conocer los entres y los pors de ActionScript (los matices más sutiles) para dar sentido a un error que, de lo contrario, juraría que no debería estar ocurriendo.

Lo que espero que hayamos hecho aquí es hacer que la primera mitad de la batalla sea más fácil de superar, para que cuando te enfrentes a los errores del mundo real en tus proyectos del mundo real, puedas recorrer la segunda mitad un poco más elegantemente.

Por último, esté atento a una serie de consejos rápidos de depuración. Este artículo proporciona el trabajo de base genérico que se hará referencia por estas futuras sugerencias rápidas. Consejos rápidos individuales se centrarán en un tipo muy específico, y típicamente común, de error que Flash le lanzará, y cómo cuidar de él cuando sucede.

Nos vemos allí, y gracias por leer.

[Nota del editor: Felicitaciones a Yuri Arcurs por su foto de Empresario Enfurecido, disponible en PhotoDune.]