7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. ActionScript

Beheben von Fehlern in AS3: Einführung

Read Time: 27 mins
This post is part of a series called How to Fix Bugs in Flash.
Quick-Tip: Throwing Errors the Clean Way
Quick Tip: How to Debug an AS3 Error #1009

German (Deutsch) translation by Federicco Ancie (you can also view the original English article)

In diesem Tutorial beschreibe ich einige der grundlegenden Informationen, die Sie zum Debuggen Ihrer Flash-Anwendungen benötigen. Das Finden und Beheben von Fehlern in Ihrem ActionScript ist keine leichte Aufgabe, daher ist dies eigentlich nur der erste Artikel einer Reihe. In dieser Folge werfen wir einen Blick auf einige der allgemeinen Dinge, die Sie tun können, um Ihre Fehler aufzuspüren.


Die verschiedenen Arten von Fehlern

Lassen Sie uns zunächst besprechen, was ein Fehler ist. Es gibt drei große Kategorien von Fehlern in keiner bestimmten Reihenfolge:

  • Compilerfehler
  • Laufzeitfehler
  • Logische Fehler

Um diese zu unterscheiden, ist es hilfreich, den Prozess der Erstellung und Präsentation einer SWF-Datei zu verstehen.

Beim Erstellen eines Flash-Films (oder einer Anwendung oder wie auch immer Sie es nennen möchten) schreiben Sie ActionScript und erstellen grafische Elemente, die vom Film verwendet werden. Sie können Flash Professional oder Flash Builder und das Flex Framework oder einen Drittanbieter-Editor und eine IDE wie FlashDevelop oder FDT verwenden. In allen Fällen wird die Arbeit, die Sie zur Erstellung Ihres Films leisten, als Authoring bezeichnet, und die Zeit, die Sie dafür aufwenden, wird als Autorenzeit bezeichnet.

Irgendwann möchten Sie die Dinge, die Ihr Autor erstellt, so sehen, wie sie es dem Endbenutzer tun würden. Bevor Sie dies jedoch sehen können, müssen die Assets zur Autorenzeit (ActionScript, Zeichnungen, Bilder, Schriftarten und Text usw.) in die SWF-Datei kompiliert werden, die der Endbenutzer sieht. Wenn Sie in Flash auf "Veröffentlichen" oder "Film testen" oder in Flash Builder auf "Ausführen" klicken, kompilieren Sie Ihre SWF-Datei. Das Programm, mit dem Sie einen Autor erstellen, nimmt Ihre Autorenzeit-Assets und kompiliert sie zu einem SWF. Die dafür benötigte Zeit wird als Kompilierungszeit bezeichnet, da die Dinge, die in dieser Phase geschehen, zur Kompilierungszeit geschehen sollen.

Schließlich können Sie die SWF-Datei im Flash Player ausführen und sehen, wie sie bei der Präsentation aussieht und funktioniert. Dies geschieht im Browser mit dem Flash Player-Plug-in oder direkt in Flash Professional, wenn Sie "Film testen" auswählen, oder als AIR-Anwendung, die auf dem Desktop (oder mobilen Gerät) ausgeführt wird. Unabhängig davon, wie die SWF-Datei präsentiert wird, läuft sie jetzt und wir erleben jetzt eine Laufzeit. Die SWF-Datei wird vom Flash Player ausgeführt und Ihr kompilierter Code und Ihre Grafiken sind sichtbar.

Normalerweise passiert all dies für Sie; Wenn Sie Flash Professional verwenden, wird durch Auswahl von "Film testen" die SWF-Datei kompiliert und anschließend in einem eigenen Flash Player ausgeführt. Wenn Sie Flash Builder verwenden, wird die SWF-Datei durch Auswahl von "Ausführen" kompiliert und dann in einem Browser gestartet. Dieser dreistufige Prozess ist im Allgemeinen etwas, über das Sie nicht nachdenken. Deshalb nehme ich mir die Zeit, um ihn ausführlich zu besprechen.

Nun zu den Fehlern und wie sie sich auf diese Phasen beziehen.

Compilerfehler sind Fehler in Ihrem Code, die zur Kompilierzeit auftauchen. An Ihrem Code stimmt etwas so grundlegend nicht, dass der Compiler innehält und sagt: "Whoah, wenn wir fortfahren, wird Ihre SWF-Datei ernsthaft durcheinander gebracht. Ich kann es nicht. Ich kann einfach nicht." Nun, OK, normalerweise ist es nicht so melodramatisch, aber es wird beim ersten Anzeichen von Problemen aufhören und sicherstellen, dass Sie nicht die Befriedigung haben, Ihre SWF-Datei ausgeführt zu sehen, bevor Sie die Probleme beheben.

Dies sind im Allgemeinen Syntaxfehler – wie fehlende oder nicht übereinstimmende Klammern – oder auch Typfehler; Dinge, die eine Maschine betrachten kann und weiß, dass sie falsch sind. Dies sind Fehler, die im Bedienfeld "Compilerfehler" in Flash Professional angezeigt werden.

The Compiler Errors PanelThe Compiler Errors PanelThe Compiler Errors PanelDas Compiler-Fehler-Panel
The Compiler Errors PanelThe Compiler Errors PanelThe Compiler Errors PanelDas Compiler-Fehler-Panel

Laufzeitfehler sind Fehler, die auftreten, während die SWF ausgeführt wird. In diesem Fall ist der Code syntaktisch korrekt, da er ohne Fehler am Compiler vorbeigekommen ist (wir wissen das, weil die SWF läuft). Aber der Code hat immer noch einen Fehler, der dazu führte, dass er auf eine Weise ausgeführt wurde, die der Flash Player nicht mag. Entweder weiß es nicht, was es mit diesem unerwarteten Ergebnis anfangen soll, oder es verursacht einen Fehler, der Sie darüber informiert, dass etwas zur Laufzeit fehlgeschlagen ist.

In diesen Fällen erhalten Sie einen offiziellen Fehler, der das Problem detailliert beschreibt und zumindest einen allgemeinen Hinweis darauf gibt, wo in Ihrem Code es aufgetreten ist. In Flash Professional sehen Sie diese, wenn Sie im Ausgabebedienfeld "Film testen" auswählen.

A run-time Error in the Output PanelA run-time Error in the Output PanelA run-time Error in the Output PanelEin Laufzeitfehler im Ausgabebereich

Logische Fehler sind im Grunde Fehler bei der Steuerung Ihres Programms. Dies sind keine Compilerfehler; die SWF wird kompiliert und ausgeführt. Dies sind keine Laufzeitfehler. Flash Player hat Ihnen keine große Fehlermeldung ins Gesicht geworfen. Alles ist technisch korrekt und funktioniert, aber sie funktionieren nicht so, wie Sie es möchten. Vielleicht hat das von Ihnen programmierte Raster eine zu viele Spalten, oder die Warenkorbsumme wird nicht korrekt berechnet, eine vom Benutzer eingegebene E-Mail-Adresse wird als inakzeptabel validiert, obwohl sie es tatsächlich ist, oder eine Bildfolge wird falsch angezeigt Auftrag.

Dies sind die am schwierigsten zu findenden Fehler, da sie nur gefunden werden können, wenn die SWF-Datei so verwendet wird, wie sie verwendet werden soll, und die tatsächlichen Ergebnisse genau mit den erwarteten Ergebnissen verglichen werden. Und einmal gefunden, erhalten Sie keine hilfreichen Fehlermeldungen, die Ihnen eine Vorstellung davon geben, was schief gelaufen ist.

Even though we got this far without compiler or run-time error, something is wrong: we're missing a zero on the price.Even though we got this far without compiler or run-time error, something is wrong: we're missing a zero on the price.Even though we got this far without compiler or run-time error, something is wrong: we're missing a zero on the price.Auch wenn wir ohne Compiler- oder Laufzeitfehler so weit gekommen sind, stimmt etwas nicht: Uns fehlt eine Null beim Preis.

Compilerfehler: Finden des Problems

Compilerfehler sind normalerweise am einfachsten zu behandeln. Das liegt daran, dass der Compiler zum einen in seinen Spuren anhält und Sie über den Fehler informiert, und zum anderen, der Compilerfehler selbst sagt Ihnen, was nicht stimmt, sagt Ihnen die Datei- und Zeilennummer und druckt sogar diese Codezeile für Ihr Referenz.

Compiler-Fehler werden im Compiler-Fehler-Bedienfeld angezeigt, also werfen wir einen genaueren Blick auf dieses spezielle Element der Flash-IDE:

The Compiler Errors Panel, AgainThe Compiler Errors Panel, AgainThe Compiler Errors Panel, AgainDas Compiler-Fehler-Panel, noch einmal

Wie Sie im obigen Diagramm mit Anmerkungen sehen können, wird jeder Fehler in einer eigenen Zeile aufgeführt. Jede Zeile besteht aus den gleichen Basisinformationen. In der ersten Spalte erhalten Sie den Dateinamen und die Zeilennummer, in der der Fehler gefunden wurde. Im obigen Beispiel tritt der Fehler in einer Klassendatei auf. Wenn Sie Code direkt im Skriptbedienfeld geschrieben haben, erhalten Sie etwas wie "Scene 1, Layer 'Layer 1', Frame 1, Line 1", was dasselbe ist, nur für nicht-textdateibasierten Code.

Es ist hilfreich zu wissen, wo der Fehler auftritt, aber die zweite Spalte enthält Informationen darüber, warum der Fehler aufgetreten ist. Das erste Bit ist die Fehlernummer, die einer ID entspricht. Jeder Fehlertyp erhält eine eigene Nummer. Es folgt eine textliche Beschreibung des Fehlers. Nun, um fair zu sein, hat Adobe einige ziemlich stumpf formulierte Fehlerbeschreibungen, und in zukünftigen Artikeln dieser Serie werden wir versuchen, einige der häufigeren zu entschlüsseln, damit Sie effektiver damit umgehen können. Bis dahin können wir zumindest erfahren, dass die Fehlernummer mit der Fehlerbeschreibung verknüpft ist. Der Text in der Beschreibung wird möglicherweise angepasst, um eine kontextbezogene Relevanz darzustellen, z. B. die Verwendung des Variablen- oder Funktionsnamens aus Ihrem Quellcode, aber der allgemeine Fehler ist an die Nummer gebunden. Fehler 1067 ist beispielsweise ein Zwangsfehler, unabhängig davon, ob es sich um eine Zwangsverknüpfung eines Strings in ein DisplayObject oder eines Arrays in ein ExternalInterface handelt.

Eine vollständige Liste der Complier-Fehler finden Sie auf dieser Seite aus der ActionScript-Dokumentation von Adobe:

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

Einige Fehler werden auf dieser Seite genauer erklärt.


Compilerfehler: Beheben des Problems

Das Tolle an Compilerfehlern ist, dass sie ziemlich einfach zu finden sind. Sie werden nicht nur angezeigt und verhindern, dass Sie Ihre SWF-Datei ausführen, sondern Sie können auch ganz einfach über das Fenster "Compiler-Fehler" auf den problematischen Code zugreifen. Doppelklicken Sie einfach auf einen Fehler im Panel und die entsprechende Quelldatei wird geöffnet, mit Ihrem Cursor in der rechten Zeile. Wenn Sie Flash Professional jetzt mit einem externen Editor verwenden, müssen Sie doppelklicken, um die Datei in Flash Professional zu bearbeiten. Dies mag gegen Ihre Gründe sein, einen externen Editor zu verwenden, aber zumindest ist die Fehlersuche normalerweise ziemlich schnell und Sie können es ziemlich schmerzlos erledigen. Selbst wenn Sie CS5 mit der engen Flash Builder-Integration verwenden, wird beim Doppelklicken auf den Fehler die Datei in Flash Professional und nicht in Flash Builder angezeigt. Flash Builder verfügt jedoch über ein eigenes Compiler-Fehlerfeld, das ähnlich funktioniert.

The Flash Builder Compiler Errors panel, or the "Problems" panelThe Flash Builder Compiler Errors panel, or the "Problems" panelThe Flash Builder Compiler Errors panel, or the "Problems" panelDas Flash Builder-Compiler-Fehlerbedienfeld oder das "Probleme"-Bedienfeld

An dieser Stelle geht es darum, zu der vom Fehler angegebenen Codezeile zu gehen und sie zu beheben.


Laufzeitfehler: Finden des Problems

Sobald Sie die Compilerfehler behoben haben, kann Ihre SWF ausgeführt werden, aber zu diesem Zeitpunkt können Laufzeitfehler auftreten. Diese treten aus verschiedenen Gründen auf – wieder werden wir sie später in dieser Serie untersuchen – aber lassen Sie uns zunächst die Anatomie eines Laufzeitfehlers untersuchen. Hier ist ein typischer Laufzeitfehler, der angezeigt wird, während die SWF-Datei von "Testfilm" in Flash Professional ausgeführt wird:

The Output panel displaying a run-time errorThe Output panel displaying a run-time errorThe Output panel displaying a run-time errorDas Ausgabebedienfeld zeigt einen Laufzeitfehler an

Es wird möglicherweise eine Menge Text an Sie ausgespuckt, wenn ein Fehler auftritt. Es mag anfangs ein wenig einschüchternd erscheinen, aber es sind wirklich nur zwei Hauptabschnitte:

The two main sections of the run-time errorThe two main sections of the run-time errorThe two main sections of the run-time errorDie beiden Hauptabschnitte des Laufzeitfehlers

Wie oben erwähnt, ist das erste Bit des Fehlers die Beschreibung dessen, was passiert ist. Wie bei Kompilierzeitfehlern hat jede Art von Laufzeitfehler eine Fehlernummer, die mit einer kurzen Textbeschreibung verknüpft ist. Die Beschreibung beinhaltet einen Fehlertyp sowie einen Nerd-Speak-Satz. Der Fehlertyp kann hilfreich sein, um einen umfassenden Überblick über die Vorgänge zu erhalten. Die Beschreibung gibt jedoch Aufschluss über das Problem. Wir schauen uns gleich ein Beispiel an.

Der zweite Hauptteil ist jeder Text, der dem ersten Bit folgt, genannt Stack-Track oder Call-Stack, und wir werden im nächsten Schritt tiefer darauf eingehen.

Wie bei Kompilierzeitfehlern lassen die textlichen Beschreibungen etwas zu wünschen übrig. Sobald Sie jedoch verstanden haben, was einige der häufiger auftretenden Fehler bedeuten, haben Sie eine Vorstellung davon, was nicht stimmt, und wissen, wo Sie suchen müssen.

Eine vollständige Liste der Laufzeitfehler ist hier dokumentiert, von denen einige mit Anmerkungen versehen sind:

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


Laufzeitfehler: Den Stack Trace verstehen

Kommen wir zum zweiten Hauptbit des Laufzeitfehlers, dem Stacktrace. Die Länge kann von einer Zeile bis zu einer endlichen, aber sehr großen Anzahl von Zeilen reichen. Der Zweck dieses Stack-Trace besteht darin, Sie darüber zu informieren, wo in Ihrem Code der Fehler aufgetreten ist.

Jede Zeile im Stack-Trace repräsentiert eine einzelne Funktionsausführung. Die oberste Zeile benennt die Funktion, in der der Fehler tatsächlich aufgetreten ist; es enthält die Codezeile, die alles in die Luft gejagt hat. Die zweite Zeile im Stack-Trace nennt die Funktion, die die Funktion aufgerufen hat, die den Fehler verursacht hat. Die dritte Zeile benennt die Funktion, die die Funktion aufgerufen hat, die die Funktion aufgerufen hat, in der der Fehler aufgetreten ist. Und... Sie bekommen die Idee. Aber lassen Sie es uns praktischer veranschaulichen. Im folgenden Code verursacht die Funktion third einen Laufzeitfehler, indem sie versucht, der Anzeigeliste "nichts" hinzuzufügen. Wir nennen es jedoch nicht sofort; Wir beginnen mit dem Aufrufen der first Funktion, die second Funktion aufruft, die wiederum schließlich die third Funktion aufruft:

Wenn Sie diesen Code in das Skriptbedienfeld einer brandneuen Flash-Datei einfügen und ausführen, wird der folgende Fehler angezeigt:

Jetzt wissen wir, dass der Fehler darauf zurückzuführen ist, dass eine nicht initialisierte Sprite-Variable an addChild gesendet wurde. Die Funktion, die den Fehler tatsächlich ausgelöst hat (das ist der Fachbegriff; wenn ein Fehler auftritt, bedeutet dies, dass der Fehler von einer bestimmten Codezeile ausgelöst wurde. Ich stelle es mir ähnlich wie einen Wutanfall vor) ist die addChild-Methode und steht daher ganz oben auf der Liste. Die nächsten drei Zeilen sind die Funktionen, die wir geschrieben haben, die zuletzt zuerst aufgeführt sind. Es endet (oder beginnt, je nachdem, wie Sie es betrachten) mit einem Aufruf von frame1 in der Hauptzeitleiste. Dies ist nur die Methode, mit der die SWF-Datei gestartet wird. Wenn Sie eine Dokumentklasse eingerichtet haben, wird dies stattdessen angezeigt. Da in diesem Beispiel nur im ersten Frame ein Skript verwendet wurde, erhalten wir frame1.

Der Punkt ist, dass der Aufruf von frame1 letztendlich zu einem fehlerhaften Aufruf von addChild führte, und Sie können diesem logischen Pfad folgen, indem Sie den Stack-Trace lesen.

Diese vollständige Liste von Funktionsaufrufen scheint nur ein Durcheinander von Informationen zu sein, die Sie nicht benötigen, aber es gibt eine Reihe von Fällen, in denen Sie Ihren Fehler eingrenzen können. Wenn der Fehler nur manchmal in der angegebenen Funktion auftritt, können Sie das Problem möglicherweise herausfinden, indem Sie die Schritte verfolgen, die zum Aufrufen der Funktion ausgeführt wurden. Wenn es zum Beispiel etwas mehr Zusammenspiel in den Funktionen gäbe:

Die third Funktion könnte der unmittelbarste Täter sein, aber eine genaue Untersuchung würde ergeben, dass die second Funktion diejenige war, die s tatsächlich zu einem null-Wert gemacht hat.


Laufzeitfehler: Der Flash Debug Player

Ein wesentliches Werkzeug für den Flash-Entwickler ist die Debug-Version des Flash Players. Wenn Sie es noch nicht installiert haben, sollten Sie mit dem, was Sie tun (diesen Artikel lesen) aufhören und es sofort herunterladen. Sie müssen Ihren Browser neu starten, da es sich um eine Neuinstallation des Flash Players handelt, also setzen Sie diese Seite zuerst als Lesezeichen!

Laden Sie das entsprechende Installationsprogramm hier herunter:

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

(Chrome-Benutzer: Lesen Sie diesen Support-Hinweis, um zu erfahren, wie Sie den integrierten Flash Player von Chrome überschreiben können.)

Sobald Sie Ihren Browser neu starten, werden Sie nicht sofort viel Unterschied bemerken. Aber probieren Sie es unten in diesem SWF aus. Zuerst sollten Sie einen Text sehen, der Ihre aktuelle Flash Player-Version angibt, einschließlich der Angabe, ob es sich um die Debug-Version handelt oder nicht. Klicken Sie jedoch auf die große Schaltfläche, die mit einer Funktion verbunden ist, die letztendlich einen Fehler auslöst. Wenn Sie dies ohne den Debug-Player ausprobieren, wird nichts passieren. der Fehler wird auftreten, wird aber stillschweigend fehlschlagen. Wenn Sie es jedoch mit dem Debug-Player versuchen, erhalten Sie eine ziemlich aufdringliche und schwer zu übersehende Fehlermeldung:

Wenn Sie zu faul sind, den Debug-Player tatsächlich zu installieren, oder nur überprüfen möchten, ob Sie es richtig gemacht haben, sollte der angezeigte Fehler ungefähr so aussehen:

The error window displayed when the debug player is installed.The error window displayed when the debug player is installed.The error window displayed when the debug player is installed.Das Fehlerfenster, das angezeigt wird, wenn der Debug-Player installiert ist.

Natürlich ist die Installation des Debug Players äußerst nützlich, um beim Testen Ihrer SWFs im Browser auf Fehler aufmerksam gemacht zu werden. Wie Sie sich vielleicht vorstellen können (oder bereits bemerkt haben), kann eine SWF-Datei, die problemlos von der Flash-IDE ausgeführt wird, in einer anderen Umgebung wie Ihrem Webserver etwas beanstanden. Stellen Sie sich vor, dass die SWF-Datei zum Laden von einer XML-Datei abhängig ist, aber wenn der Pfad zu dieser XML-Datei auf dem Webserver im Vergleich zu Ihrer lokalen Entwicklungsumgebung falsch aufgelöst wird, tritt ein Ladefehler auf. Es wäre sicherlich nützlich, dies sofort zu erfahren, anstatt mit einer nicht funktionierenden SWF und ohne Hinweise konfrontiert zu werden.

Der Nachteil des Debug-Players ist, dass es eher um alles oder nichts geht; Sie können keine Websites debuggen, die Sie nicht entwickeln. Das heißt, wenn Sie nur im Internet surfen, lösen Sie möglicherweise Laufzeitfehler in anderen SWFs aus. Es ist ärgerlich und gibt Ihnen eine Vorstellung davon, wie wenig einige Entwickler auf ihren Testprozess achten.

Als zusätzlicher Tipp können Sie leicht feststellen, ob Sie die reguläre oder die Debug-Version des Players haben, indem Sie einfach mit der rechten Maustaste auf eine beliebige SWF-Datei klicken und darin nach den Optionen "Neuzeichnen-Regionen anzeigen" und "Debugger" suchen:

The Flash Player context menu, when invoked from a debug playerDas Flash Player-Kontextmenü, wenn es von einem Debug-Player aufgerufen wird

Laufzeitfehler: Debuggen zulassen

Unabhängig davon, ob Sie Laufzeitfehler in der IDE oder im Browser anzeigen oder nicht, ein Fehler ist nur bis zu einem gewissen Punkt informativ. Wenn irgendwo in einer Funktion ein Fehler auftritt, diese Funktion jedoch 20 Zeilen lang ist, können Sie möglicherweise ein wenig Schwierigkeiten haben, festzustellen, wo sich die fehlerhafte Codezeile befindet.

Es gibt zwei Techniken, die zu den gleichen Ergebnissen führen, da für jeden Funktionsaufruf mehr Informationen in Form der betreffenden Codezeile bereitgestellt werden.

Die erste Technik ist direkter: Anstatt Befehl-Eingabetaste/Strg-Eingabetaste zu drücken, um Ihren Film zu testen, drücken Sie Befehlstaste-Umschalttaste-Eingabetaste/Strg-Umschalttaste-Eingabetaste, um Ihren Film zu debuggen. Dadurch wird die SWF-Datei im Flash Player-Debugger gestartet, wobei eine Debugging-Sitzung gestartet wird. Wenn ein Laufzeitfehler ausgelöst wird, kehren Sie zur Flash-IDE zurück (die sich selbst in einen Debug-Arbeitsbereich rekonfigurieren sollte) und Sie sehen etwas mehr Informationen im Stack-Trace (beachten Sie insbesondere die Zeilennummern, die zu hinzugefügt wurden) die Ausgabe unten):

Als Bonus öffnet Flash wenn möglich die Datei, die für das Auslösen des Fehlers verantwortlich ist, und zeigt auf die fragliche Zeile. Viele integrierte Fehler treten tatsächlich innerhalb von integrierten Klassen auf, und daher ist es nicht möglich, diesen Code anzuzeigen. Aber wenn Sie es in Aktion sehen möchten, versuchen Sie den folgenden Code:

...und führen Sie es durch Debug Movie aus. Zeile 7 sollte aufgerufen werden.

Wie bereits erwähnt, müssen Sie jedoch manchmal auf einem Server und über einen Browser testen, und die Debugging-Funktionen der Flash-IDE sind in dieser Hinsicht weniger nützlich. Mit dem Debug-Player, den wir im letzten Schritt installiert haben, gibt es eine Möglichkeit, die Zeilennummerninformationen im Laufzeitfehlerfenster abzurufen. Dies ist so einfach wie das Aktivieren einer Veröffentlichungsoption.

Wählen Sie in Ihrem Flash-Dokument Datei > Veröffentlichungseinstellungen… und klicken Sie dann auf die Registerkarte Flash. Unten sehen Sie unter der Überschrift "Erweitert" eine Kontrollkästchenoption für das Debuggen zulassen. Stellen Sie sicher, dass dies aktiviert ist, und klicken Sie dann auf "OK".

The Permit Debugging option in the Flash Publish settingsThe Permit Debugging option in the Flash Publish settingsThe Permit Debugging option in the Flash Publish settingsDie Option Debugging zulassen in den Flash-Veröffentlichungseinstellungen

Veröffentlichen Sie die SWF-Datei erneut und führen Sie die erforderlichen Schritte aus, um sie erneut in Ihrem Browser auszuführen. Wenn jetzt ein Laufzeitfehler auftritt, sehen Sie dieselben Zeilennummerninformationen.

Runtime error in the browser, with line numbersRuntime error in the browser, with line numbersRuntime error in the browser, with line numbersLaufzeitfehler im Browser, mit Zeilennummern

Sie haben nicht die Möglichkeit, zum Quellcode zu springen, aber dieser Zeilennummern-Trick kann Ihnen eine Menge Zeit beim Aufspüren von Fehlern sparen.

Achten Sie jedoch darauf, das Debuggen von Genehmigungen zu deaktivieren, wenn Sie bereit sind, die SWF-Datei weltweit bereitzustellen. Flash muss der SWF-Datei zusätzliche Informationen hinzufügen, um die Zeilennummern bereitzustellen, und die resultierende Dateigröße der SWF-Datei ist normalerweise 25 - 50% höher als normalerweise. Es ist ein nützliches Debugging-Tool, aber nicht etwas, das Sie einfach für alles überall aktivieren sollten.


Laufzeitfehler: Werfen Sie Ihre eigenen

Ich habe bereits erwähnt, dass es möglich ist, Ihre eigenen Fehler zu verursachen (und Ihre eigenen Wutanfälle, aber ich werde nur beschreiben, wie Sie ersteres tun). Dies kann eine hilfreiche Technik beim Debuggen sein. Wenn Sie beispielsweise folgende Funktion haben:

Und diese Funktion ist ein wesentlicher Bestandteil der Funktionalität des Rests Ihres Films (vermutlich können wir mit dem XML-gesteuerten Teil nicht fortfahren, wenn das XML nicht geparst wird), dann könnten Sie eine unangenehme Wendung erleben, wenn das XML Objekt, das an die Funktion übergeben wird, ein null-Objekt ist oder möglicherweise nicht der von Ihnen erwarteten Struktur entspricht.

Sie können daher in dieser wichtigen Funktion in Betracht ziehen, einige Überprüfungen einzurichten und, falls die Überprüfungen fehlschlagen, einige Fehler auszulösen. So einfach kann es sein:

Streng genommen möchten Sie wahrscheinlich den ArgumentError anstelle des einfachen alten Error verwenden, aber das Ergebnis ist im Wesentlichen das gleiche. Wenn Sie diesen Code ausführen:

Sie sehen einen hilfreichen Fehler:

The runtime errorThe runtime errorThe runtime errorDer Laufzeitfehler

Außerdem können Sie davon ausgehen, dass die XML möglicherweise nicht null ist, aber möglicherweise auf eine Weise bearbeitet wird, die nicht den Erwartungen der Parsing-Funktion entspricht. Wenn ein Knoten namens <entries> mit untergeordneten Knoten namens <entry> gefüllt werden soll, die XML-Datei jedoch aufgrund eines menschlichen Versagens so aussah:

Dann würde das Parsen nicht funktionieren. Davor können Sie sich schützen:

Und Sie sollten diesen Fehler erhalten:

Another helpful run-time errorAnother helpful run-time errorAnother helpful run-time errorEin weiterer hilfreicher Laufzeitfehler

Sie können sich selbst oder jemand anderen etwas Zeit sparen, wenn XML-Dateien falsch bearbeitet werden.


Laufzeitfehler: Holen Sie sich den Stack-Trace ohne Fehler

Manchmal ist die Stapelverfolgung für sich genommen nützlich, selbst wenn kein Fehler aufgetreten ist. Zum Beispiel finde ich mich hin und wieder mit einer Methode wieder, die häufiger aufgerufen wird, als ich denke, dass es sollte. Wenn ich nur sehen könnte, welche anderen Methoden es aufrufen, könnte ich herausfinden, woher der zusätzliche Aufruf kommt.

Fehler auf den ersten Blick scheinen eine geeignete Lösung zu sein. Aber ein Fehler neigt dazu, einen Flash-Film in seinen Bahnen zu stoppen. Wenn der erste Fehler mir einen Stack-Trace gibt, kann dies verhindern, dass der zweite Aufruf jemals stattfindet, da der erste Fehler dies verhindert hat. In diesen Situationen ist es gut, ein wenig mehr über Error-Objekte zu erfahren.

Am nützlichsten ist die Methode getStackTrace, die den Stack-Trace so zurückgibt, wie er angezeigt würde, wenn der Error ausgelöst würde. Das Schöne ist jedoch, dass es nicht wirklich geworfen werden muss, um diese Informationen zu erhalten. Wenn Sie also einfach nur neugierig sind, den Stack-Trace ohne Fehler zu sehen, können Sie Folgendes tun:

Wenn Sie dies in der Flash-IDE anzeigen, sind die Unterschiede zwischen diesem und einem ausgelösten Fehler schwer zu erkennen. Beide geben einfach eine Reihe von Informationen an das Ausgabebedienfeld aus. Sie könnten erwägen, die Spur zu verschönern, um den Unterschied leichter zu erkennen. Wenn Sie jedoch im Browser testen, zeigt dieser Code nicht das Fehlerfenster an, sondern schreibt einfach zur Kenntnisnahme in das Flash-Protokoll (ich gehe vor mir, das Tracing aus dem Browser wird in wenigen Schritten behandelt).


Verfolgen Sie den Teufel aus allem

Apropos Traces: Wenn es um Debugging geht, ist Tracing das beste Werkzeug, das Ihnen zur Verfügung steht. Sicher, Flash Professional und Flash Builder verfügen beide über Debugger, mit denen Sie Breakpoints setzen, Code schrittweise durchlaufen und Variablen überprüfen können, aber ehrlich gesagt finde ich den schnellsten Weg zwischen dem Fehler und dem Sammeln von genügend Informationen, um ihn zu beheben, eine Handvoll vernünftig platzierter Traces. Traces sind nützlich, um sowohl Laufzeit- als auch logische Fehler zu debuggen, aber da wir über Tools verfügen, um Informationen über Laufzeitfehler zu erhalten, können Traces die erste Verteidigungslinie gegen logische Fehler sein.

Wenn ich einen logischen Fehler behebe, weiß ich normalerweise, worauf ich mich konzentrieren muss. Das, was nicht funktioniert, ist normalerweise in eine oder zwei Klassen und normalerweise in eine Handvoll Methoden und Eigenschaften lokalisiert. Also, innerhalb der potenziellen Problembereiche verfolge ich alles.

In der Praxis tendiere ich dazu, Folgendes zu tun:

  • Fügen Sie einen Trace als erste Anweisung innerhalb einer Funktion oder Methode zusammen mit einer Ausgabe von Parametern ein, um sicherzustellen, dass Funktionen aufgerufen werden und die Parameter meinen Erwartungen entsprechen.
  • Verfolgen Sie jede Variable oder Eigenschaft, die in der Funktion verwendet wird, mindestens einmal. Wenn sich die Eigenschaft während der Funktion ändert, setzen Sie eine Spur vor und nach der möglichen Änderung.
  • Verfolgen Sie alle bedingten Anweisungen, nur um zu kennzeichnen, zu welchem Zweig Sie gelangen.
  • Verfolgen Sie alle Iterationen von Schleifen, normalerweise mit einigen Informationen über die Iteration (wie die Indexnummer und/oder das Objekt aus dem Array, das für diese Iteration relevant ist)
  • Wenn eine Variable ein komplexes Objekt ist, wie ein Sprite oder ein Sound, verfolgen Sie mehrere Eigenschaften des Objekts

Als stilistische Regel finde ich es immens nützlich, auch die Spur zu beschriften. Das heißt etwa so:

Auf diese Weise können Sie, nachdem Sie Ihrem Code ein Dutzend Spuren hinzugefügt haben, diejenige, die null sagt, unter allen anderen Spuren leichter identifizieren.

Darüber hinaus möchten Sie vielleicht sogar den Namen der Klasse (und der Methode) in Ihren Ablaufverfolgungen voranstellen, um die Quelle jedes Ablaufverfolgungsvorgangs besser identifizieren zu können.

Es gibt keine festen Regeln für die Rückverfolgung, nur meine allgemeine Empfehlung, alles zu verfolgen, auch Dinge, von denen Sie glauben, dass Sie sie nicht brauchen, nur um sicher zu gehen. An dieser Stelle ist eine Frage an die Leser angebracht: Auf welche Trace-Techniken verlassen Sie sich? Fühlt euch frei, in den Kommentaren einen Flammenkrieg zu starten.

[Anmerkung der Redaktion: Bitte in den Kommentaren keinen Flame War starten.]


Tracing: Trace aus dem Browser

Ein weiterer Vorteil des Debug-Players (natürlich für den Flash-Entwickler) ist die Möglichkeit, Ihre Spuren im Browser anzuzeigen, sodass Sie eine SWF-Datei in ihrem natürlichen Lebensraum effektiver testen und debuggen können.

Leider müssen Schritte unternommen werden, um diese Ablaufverfolgung zu aktivieren, und ich werde nicht wiederholen, was an anderer Stelle geschrieben wurde. Eine Suche nach "Flash-Debug-Trace" führt zu vielen Artikeln mit Anleitungen, von denen mein Favorit derzeit ganz oben auf der Liste von Google steht, ein ausführlicher Artikel auf yourpalmark.com, der verschiedene Versionen des Players für Mac und Windows behandelt, und Linux-Systeme.

Ich werde einen Tipp für Macintosh-Benutzer hinzufügen. Die Console-Anwendung wird im verlinkten Artikel nur am Rande erwähnt, aber nicht wirklich erklärt oder meiner Meinung nach richtig genutzt. Die Konsole wird mit Mac OS X installiert und befindet sich im Ordner /Programme/Dienstprogramme. Es ist ideal zum Anzeigen von Protokolldateien, die Ihre Debug-Player-Traces tatsächlich sind. Es ist klug, nach unten zu scrollen, wenn Sie bereits ganz unten sind, aber nicht, wenn Sie es nicht sind. Es ist einfach, das Protokoll zu filtern und zu durchsuchen, und ich finde es unverzichtbar für die Flash-Entwicklung.

The Mac's Console application in use for Flash tracesThe Mac's Console application in use for Flash tracesThe Mac's Console application in use for Flash tracesDie Mac-Konsolenanwendung, die für Flash-Traces verwendet wird

Der Trick besteht jedoch darin, dass Console zwar jede beliebige Textdatei öffnen kann, sich aber nur Dateien merkt, wenn sie sich an den Standardspeicherorten für Protokolldateien auf Ihrem System befinden und wenn es sich um .log-Dateien handelt. Der Flash-Debug-Player schreibt jedoch nur Traces in eine Datei namens flashlog.txt, die sich an einem nicht standardmäßigen Speicherort der Protokolldatei befindet. Es gibt einen einfachen Terminalbefehl, mit dem Sie einen symbolischen Link an der richtigen Stelle erstellen können:

Ich habe mehr über diesen Trick im Flash-Blog meiner Firma hier geschrieben: http://summitprojectsflashblog.wordpress.com/2008/12/17/leopards-console-and-flash-debug-player-traces/


Der Flash-Debugger

Wie bereits erwähnt, bieten sowohl Flash Professional als auch Flash Builder Debugger-Umgebungen. Diese halte ich persönlich für eingeschränkt brauchbar, da ich mich lieber auf Traces und Laufzeitfehler verlasse. Außerdem hängt die effektive Verwendung des Debuggers davon ab, dass Sie Breakpoints setzen können, was nur(einfach) in Code möglich ist, der in Flash Professional oder Flash Builder geöffnet ist. Persönlich verwende ich TextMate als Editor meiner Wahl, was das Setzen von Breakpoints umständlich macht. Ich wäre jedoch nachlässig, wenn ich den Flash-Debugger nicht in einem Artikel über Flash-Debugging erwähnen würde.

Hier finden Sie eine kurze Übersicht über die Debugging-Tools, die Sie mit Flash Professional erhalten. Kehren wir zu unserem Beispiel zur Erzeugung von Laufzeitfehlern von vorhin zurück. Fügen Sie diesen Code in das Skriptbedienfeld einer Flash-Datei ein:

Bevor Sie jedoch auf Debug Movie klicken, klicken Sie im Skriptbedienfeld links neben der Zahl "5".

The breakpoints columnThe breakpoints columnThe breakpoints columnDie Breakpoints-Spalte

In der Spalte wird ein roter Punkt angezeigt, der anzeigt, dass ein Breakpoint gesetzt wurde. Um einen Haltepunkt zu entfernen, klicken Sie einfach erneut darauf. Wenn der Breakpoint in Zeile 5 gesetzt ist (wo second innerhalb von first aufgerufen wird), fahren Sie fort und debuggen Sie den Film. Nun erwarten wir, dass der Debug-Workspace aufgrund des Fehlers übernimmt, aber wenn Sie bemerken, was passiert, ist der Fehler (noch) nicht aufgetreten. Ein gelber Pfeil zeigt auf Zeile 5 und zeigt an, dass die Programmausführung an unserem Haltepunkt angehalten wird. An diesem Punkt haben wir die Möglichkeit, den Code Zeile für Zeile durchzugehen und dabei den Wert der Variablen zu überprüfen, um unseren Fehler zu finden.

We've hit the breaking pointWir haben die Sollbruchstelle erreicht

Richten Sie Ihre Aufmerksamkeit auf das Variablenbedienfeld in der unteren rechten Ecke.

The Variables panelThe Variables panelThe Variables panelDas Variablen-Panel

Öffnen Sie den Eintrag this, und Sie sehen eine verschachtelte Liste aller Eigenschaften, die zu "this" gehören, der Hauptzeitleiste unserer SWF. Scrollen Sie nach unten und Sie sehen "s", unsere Sprite-Variable. Möglicherweise müssen Sie das Panel breiter machen, aber die zweite Spalte sollte einen Wert enthalten, wie flash.display.Sprite, der anzeigt, dass sie einen Wert enthält.

The Variables panel, with the s variable exposedThe Variables panel, with the s variable exposedThe Variables panel, with the s variable exposedDas Variablen-Panel mit der exponierten s-Variablen

Beachten Sie, dass dieses Bedienfeld verwendet werden kann, um den Wert zu überprüfen, der sich zum Zeitpunkt des Anhaltens des Films in allen Eigenschaften befindet. Beachten Sie auch, dass Sie bei angehaltenem Film auf einige der Wertefelder doppelklicken und neue Werte eingeben können. Dies funktioniert nur bei primitiven Werten wie String und Number, aber es ist eine praktische Technik, die man kennen sollte.

Bewegen Sie nun Ihre Augen nach oben zum Debug Console-Bedienfeld. Hier können wir das Anhalten und die Ausführung unseres Codes steuern. Oben im Bedienfeld befinden sich eine Reihe von Schaltflächen. Suchen Sie nach diesem:

The Step In buttonThe Step In buttonThe Step In buttonDie Step In-Schaltfläche

Klicken Sie einmal darauf und Sie werden feststellen, dass der gelbe Pfeil von Zeile 5 zu Zeile 7 vorgerückt ist. Dies zeigt an, was passiert ist; Wir haben Zeile 5 vollständig ausgeführt, was einen Aufruf der in Zeile 7 deklarierten Funktion beinhaltet. Der nächste Schritt in unserem Programm besteht darin, diese Funktion aufzurufen. Überprüfen Sie unsere s-Variable im Variablenbedienfeld. Es sollte immer noch einen Sprite-Wert haben.

Klicken Sie erneut auf die Schaltfläche Step In. Der gelbe Pfeil sollte auf Zeile 8 zeigen, wo wir s auf null setzen. Wenn Sie jedoch das Variablenbedienfeld erneut überprüfen, wird s immer noch einen Wert haben. Dies liegt daran, dass wir in Linie 8 pausiert sind, aber bevor Linie 8 tatsächlich fährt.

Klicken Sie erneut auf die Schaltfläche Einsteigen. Überprüfen Sie mit dem gelben Pfeil nach Zeile 8 die Eigenschaft s im Bedienfeld "Variablen". Is sollte jetzt null sein. Wenn dieses Beispiel nicht so einfach wäre, könnten wir jetzt feststellen, dass der Code, den wir gerade ausgeführt haben, dafür verantwortlich ist, unsere Eigenschaft auf null zu setzen, was wiederum unseren Fehler verursacht.

An dieser Stelle haben wir uns davon überzeugt, dass dies die Ursache des Fehlers ist, sodass Sie nicht ständig Code durcharbeiten müssen. Wir können die grüne Schaltfläche Weiter drücken, wodurch die normale Ausführung fortgesetzt wird, und Sie sollten dann sehen, dass der Fehler auftritt.


Einpacken

Wie sie in den 80ern sagten: Jetzt wissen Sie, und Wissen ist die halbe Miete. Jetzt sollten Sie einige Debugging-Techniken kennen und vielleicht erfahren, warum einige Fehler an verschiedenen Stellen auftauchen.

Leider ist es immer noch nur die halbe Miete, die Fakten des Debuggens zu kennen. Die andere Hälfte ist viel schwieriger in einem Tutorial zu schreiben. Bei der anderen Hälfte geht es mehr um Erfahrung und Intuition. Nachdem Sie Hunderte von Fehlern behoben haben, bekommen Sie ein Gefühl dafür, worum es bei einem bestimmten Fehler wirklich geht. Sie müssen auch die Besonderheiten von ActionScript kennen – die eher subtilen Nuancen –, um einen Fehler zu verstehen, von dem Sie sonst schwören würden, dass er nicht passieren sollte.

Ich hoffe, wir haben hier die erste Hälfte des Kampfes einfacher gemacht, damit Sie sich, wenn Sie in Ihren realen Projekten mit den realen Fehlern in Ihrer realen Welt konfrontiert sind, ein wenig mehr durch die zweite Hälfte kämpfen können elegant.

Schließlich sollten Sie nach einer Reihe von Quick-Tipps zum Debuggen Ausschau halten. Dieser Artikel bietet die allgemeine Grundlage, auf die in diesen zukünftigen Quick Tips verwiesen wird. Individuelle Quick-Tipps konzentrieren sich auf eine sehr spezifische und normalerweise häufige Art von Fehler, die Flash auf Sie auslöst, und darauf, wie Sie sich darum kümmern können, wenn dies auftritt.

Wir sehen uns dort und danke fürs Lesen.

[Anmerkung der Redaktion: Ein großes Lob an Yuri Arcurs für sein Foto des wütenden Geschäftsmanns, das auf PhotoDune verfügbar ist.]

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Scroll to top
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.