Fehler in Scripts finden

[Sascha]

Manchmal stößt man offenbar sehr früh auf (Compilier-)Fehler und weiß nicht, wie man sie beheben kann. Eine generelle Anleitung dafür, wie man einen Fehler repariert, kann ich unmöglich schreiben, da es potentiell eine unendliche Anzahl von verschiedenen Fehlern gibt, die man machen kann.

 

Sehr wohl aber helfen kann ich beim ersten Schritt zur Fehlerbehebung eines Compilierfehlers in einem Unity-Script: Den Fehler zu finden.

 

Fehler in Scripts finden

 

Compilierfehler

Zuerst einmal eine kurze Unterscheidung.

Ich unterscheide hier zwischen drei Sorten von Fehlern:

1. Compilierfehler
   Man schreibt hf9(J=)JHUG oder vergleichbaren Blödsinn in ein Script. Unity zeigt einen Fehler unten links an und weigert sich ggf., das Spiel zu starten.
   
2. Laufzeitfehler
   Das Spiel startet, aber mitten im Spiel gibt es eine Fehlermeldung.
   Im Anschluss passiert etwas unvorhergesehenes (oder etwas vorhergesehenes nicht) oder das Spiel (oder der Editor) stürzt sogar ab.
   
3. Verhaltensfehler
   Das Spiel startet, läuft durch und wirft keine Fehlermeldung. Trotzdem verhält sich das Spiel nicht so, wie es soll.
   

Diese drei Fehlertypen sind in der Informatik bekannt (wenn ihr also vorhabt, ein Informatikstudium anzufangen, merkt sie euch ) und gelten in Unity genau wie bei jeder anderen Softwareentwicklung.

 

Ich möchte mich kurz mit Typ 1 und 2 beschäftigen, da es mir um Fehlermeldungen in Unity geht.

 

Die Konsole und deren Meldungen

Die Konsole ist in Unity ein Editorfenster (so wie Scene View, Project View oder Inspector).

Man kann sie über das Menü oben im Editor unter "Window" öffnen, oder alternativ mit Strg+Shift+C.

 

Die Konsole zeigt alle Meldungen an, die irgendein Code wirft, sei er von Unity, Mono oder einem der Scripts, die du geschrieben hast.

Die oberste Meldung ist die erste, die darunter sind alle später gekommen.

Es gibt drei Arten von Fehlermeldungen:

• Logs: Kleine Hinweise oder Meldungen, dass irgendetwas passiert ist, aber nichts schlimmes.
  Wird durch eine Sprechblase markiert.
  
• Warnungen: Hinweise darüber, dass etwas unvorhergesehenes oder potentiell schlechtes passiert ist, aber (bisher) nicht kritisches.
  Ursachen sollten behoben werden, haben aber keine dringende Priorität.
  Wird durch ein gelbes Warndreieck und gelben Text dargestellt.
  
• Fehlermeldungen: Ein Fehler ist aufgetreten. Passiert dies beim Compilieren, ist es ein Compilierfehler, der Code insgesamt ist ungültig und das Spiel kann nicht gestartet oder gebuildet werden.
  Passiert es im Spiel, dann ist es ein Laufzeitfehler und zieht einen Absturz oder Fehlverhalten des Spiels nach sich.
  In jedem Fall müssen Fehlerquellen behoben werden.
  Wird durch ein rotes Stopschild und roten Text dargestellt.
  

Die letzte erstellte Meldung steht auch unten links im Unity Editor.

Steht dort nichts, so ist auch die Konsole leer (praktisch)!

 

Hier ein Bild einer geöffneten Konsole:

 

Hier sieht man schön die drei Meldungstypen. Scripts in Angry Bots haben an den Qualitätseinstellungen rumgewerkelt und melden das der Konsole, rein zur Information.

Die Warnung besagt, dass mein frisches Windows noch gerne einen Patch hätte. Der Editor und alles andere funktionieren aber trotzdem.

Mein Script enthält einen Fehler, und das ist schon kritischer.

Der Editor weigert sich das Spiel zu starten und sagt:

All compiler errors have to be fixed before entering playmode!

 

Die Einzelteile einer Fehlermeldung

Sehen wir uns meinen Fehler mal genauer an.

Die Fehlermeldung besteht aus folgenden Teilen:

• Asstes/FehlerScript.js
  Fehlerort: In dieser Datei wurde der Fehler gefunden bzw. ist hier aufgetreten.
  Doppelklicken auf die Fehlermeldungszeile öffnet diese Datei.
  
• (5,9)
  Fehlerposition: Der Fehler liegt in Zeile 5, Spalte 9 oder ist dort aufgetreten. Wichtig ist insbesondere die Zeile.
  Benutzt man einen von Unity unterstützten Scripteditor, öffnet Unity beim Doppelklick nicht nur die Datei, sondern markiert auch diese Zeile.
  
• BCE0005
  Fehlercode: Jeder Fehlertyp hat seinen eigenen Code. Diesen kann man wunderbar benutzen, um nach dem Fehler zu googeln.
  
• Unknown Identifier: 'unbekannteMethode'.
  Fehlerbeschreibung: Hier versucht Unity, uns zu beschreiben, was schief läuft. Leider sind die Fehlerbeschreibungen manchmal schwer zu verstehen und in Unity fehlen sie sogar manchmal.
  

Soweit, so gut. Jetzt wissen wir, wo der Fehler steckt oder aufgetreten ist, können danach googeln oder anhand der Beschreibung vielleicht sogar selbst beheben.

Keine Sorge wenn letzteres nicht auf Anhieb klappt - bis man von den häufigsten Fehlermeldungen raus hat, wann sie auftauchen und was das bedeutet, braucht man eine Menge Übung.

 

Aber leider ist nicht alles immer Gold, das glänzt.

 

Fehlerhafte Fehlermeldungen

Ganz am Anfang schrieb ich ja, dass es potentiell unendlich verschiedene Möglichkeiten gibt, Fehler zu machen.

Leider sind Compiler nur Programme, und die können nicht wirklich intelligent arbeiten und damit alle Fälle abdecken.

Eher früher als später produziert man daher einen Fehler, den der Compiler nicht richtig erkennt.

Bei Compilerfehlern sind die Abweichungen meist nicht so krass, bei Laufzeitfehlern dafür oft umso schlimmer.

 

Beispiel Compilerfehler:

var a : int 7;

Ich will hier meiner Variable a den Wert 7 zuweisen und habe mein Gleichzeichen vergessen. Tippfehler. Kommt vor.

Der Compiler denkt jetzt aber, dass ich das hier schreiben wollte:

var a : int; 7;

7 ist schließlich auch ein Ausdruck.

Der Fehler, den ich seiner Meinung nach also gemacht habe, ist, das Semikolon vergessen zu haben.

Und genau das zeigt er mir an. Traue also nie der Fehlerbeschreibung.

 

Beispiel Laufzeitfehler:

var go : GameObject;
//ganz viel code, in dem go keinen Wert kriegt
go.transform.Translate(1,0,0);

Hier will ich auf ein GameObject zugreifen, das ich nicht habe (go wurde kein Wert zugewiesen).

Das bedeutet eine NullReferenceException (Fehler) und ein Abbruch des Scripts, in dem das passiert.

Und für welche Zeile wird der Fehler angezeigt? Natürlich in der letzten, da da das Problem auftritt. Der tatsächliche Fehler liegt aber darüber, da irgendwo der Wert hätte zugewiesen werden müssen. Die angegebene Zeile ist also hier nicht die Zeile, in der der Fehler liegt, sondern die, in der der Fehler auftritt.

 

Selber melden

In Unity kann man wie folgt selber Meldungen erstellen (diese sind manchmal aufschlussreich bzw. aufschlussreicher als die Alternative):

• Debug.Log(meldung)
  Erstellt eine Logmeldung
  
• Debug.LogWarning(warnung)
  Erstellt eine Warnmeldung.
  
• Debug.LogError(fehler)
  Erstellt eine Fehlermeldung.
  

Um das Beispiel von eben zu verwenden:

var go : GameObject;
//ganz viel code, in dem go keinen Wert kriegt
if(go != null)
{
 go.transform.Translate(1,0,0);
}
else
{
 Debug.LogError("Das GameObject wurde nicht zugewiesen!");
}

 

Zum Abschluss

Ich hoffe, wer dieses Tutorial liest, kann hinterher eigenständig mit Fehlern und der Konsole umgehen und dieses Wissen nutzen, um sich nicht stundenlang voller Frust mit einem Fehler rumschlagen zu müssen, sondern ihn selber reparieren und ansonsten schnelle Hilfe bekommen kann.

 

Happy Coding!

[malzbie]

Sehr schön! Das sollte vielen Neulingen helfen.

[AgentCodeMonk]

Vorschlag: sowas wie try{int i = 1 / null;} catch(System.Exeption e){Debug.Log(e);} sollte da nicht fehlen, denke ich. an sowas kann man sich dann gleich gewöhnen. (bin aber gerade nicht sicher ob es in JS genauso aussieht, da ich nur noch c# nutze)

[Sascha]

Umgebungs- und Programmierfehler mit Exceptions abfangen gehört, glaube ich, nicht in die selbe Kategorie wie erste Schritte mit dem Debugger

[AgentCodeMonk]

Naja, "Debugger" kann man das ja nicht so unbedingt nennen... aber das ist ja ne andere Kiste.

Vlt hab ich was übersehen, aber ...das topic heißt ja "Fehler in Scripts finden". Von "Erste Schritte..." oder sowas wie "print nutzen für Anfänger" las ich nichts. Du hast ja Fehler zur Laufzeit angesprochen...und wenn man eh dabei ist. Fehler werden ja gefunden... Und mal ehrlich, soooo extrem advanced ist das nun auch nicht. Wer es schafft Fehler erst zur Laufzeit zu erzeugen, der schafft auch das bisschen catchen.

Davon abgesehen war es ja auch nur ein Vorschlag...

[Sascha]

Hast Recht, ein Debubgger ist das gar nicht.

Du unterschätzt aber ganz stark Anfänger in Sachen Fehlerproduktion

[AgentCodeMonk]

...hmmm. möglicherweise hast du recht... ich meine, wenn man jahrenlang hackt sind so sachen selbstverständlich;) davon abgesehen ist das anwenden eh situationsbedingt. ...und das muss man üben, üben, üben...