3.6Fehlersuche

Beim Programmieren Ihrer ersten App ist wahrscheinlich der eine oder andere Fehler aufgetreten. Dabei haben Sie schon die ersten Möglichkeiten zur Fehlersuche kennengelernt, als Xcode Sie vor oder nach der Übersetzung auf Fehler hingewiesen hat. Außerdem hat Xcode Ihnen vielleicht Warnungen angezeigt. Der Issue-Navigator (siehe Abbildung 3.85), den Sie über die Tastenkombination + erreichen, zeigt Ihnen alle Fehler mit roten Punkten und Warnungen mit gelben Dreiecken zu Ihrem Code an. Sie gelangen durch Anklicken eines Fehlers oder einer Warnung direkt zu der entsprechenden Programmstelle.

Abbildung 3.85 Der Issue-Navigator

Dabei unterscheiden sich Fehler und Warnungen darin, dass sich ein fehlerhafter Code nicht übersetzen oder gar ausführen lässt. Erhalten Sie bei der Übersetzung nur Warnungen, erzeugt Xcode trotzdem ein ausführbares Programm. Allerdings produziert dieses Programm möglicherweise Laufzeitfehler, die es ganz oder teilweise unbrauchbar machen. Sie sollten also Ihren Programmcode immer so formulieren, dass auch keine Warnungen bei der Übersetzung auftreten.

Wenn Sie den Menüpunkt Product • Analyze auswählen, untersucht Xcode den Programmcode genauer. Der Analyzer findet eine Reihe von logischen Programmfehlern, die sich unter Umständen auch erst zur Laufzeit bemerkbar machen, und stellt die Fundstellen über blaue Symbole in Xcode dar. Er kann beispielsweise einige Arten von Speicherlecks oder die Verwendung nicht initialisierter Variablen aufdecken. Zwar hat Apple mit der Einführung des Automatic Reference Countings die Gefahr von Speicherlecks erheblich gemindert; der Analyzer entdeckt jedoch auch Speicherverwaltungsfehler bei der Verwendung der C-Bibliotheken von Apple (z. B. Core Foundation). In Abbildung 3.86 sehen Sie eine typische Analyzer-Meldung für einen solchen Fehler.

Abbildung 3.86 Analyzer-Meldung in Xcode

3.6.1Logging

Eine weitere einfache Möglichkeit der Fehlersuche ist die Verwendung des Loggings. Mit dem Logger können Sie beliebige Texte in die Konsole schreiben. Wenn Sie Ihre App über Xcode ausführen, sehen Sie die Konsole in einem Teil des Debugger-Bereichs. Diesen Bereich können Sie auch über das Menü View • Debug Area • Show Debug Area oder die Tastenkombination ++ öffnen.

Wenn Sie die App auf einem Gerät nicht über Xcode gestartet haben, lässt sich ihre Ausgabe trotzdem über Xcode ansehen, indem Sie den Organizer über den Menüpunkt Window • Organizer öffnen. Dort wählen Sie den Reiter Devices und unter dem gewünschten Gerät den Punkt Console aus.

Über die Funktion NSLog können Sie eine Ausgabe ins Log schreiben. Der Aufruf dieser Funktion ähnelt dem der C-Funktion printf, die Sie vielleicht kennen. NSLog erlaubt Ihnen also formatierte Ausgaben – mit dem Unterschied, dass NSLog einen Objective-C-String als ersten Parameter erwartet, für den Sie möglichst immer ein String-Literal der Form @"..." und keine Variable verwenden sollten. Der LLVM Compiler 4.0 gibt für Variablen im Formatparameter sogar eine Warnung aus.

Hier sind einige Beispiele für Ausgaben mit NSLog:

NSLog(@"Hallo Welt");
NSLog(@"angle=%.2f", theAngle);
NSLog(@"x=%.1f, y=%.1f", thePoint.x, thePoint.y);
NSLog(@"current time=%@", [NSDate date]);
NSLog(@"frame=%@", NSStringFromCGRect(self.frame));

Listing 3.73 Ausgaben mit »NSLog«

Sie sollten darauf achten, dass Sie Objekte der Klasse NSString nicht über das Format %s, sondern über %@ ausgeben. Das Format %s verwenden Sie für C-Strings, also für Zeiger auf char. Das Format %@ benutzen Sie hingegen für Objekte beliebiger Klassen. Dabei verwendet NSLog für die Ausgabe die Rückgabe der Methode description des Objekts. Diese Methode stellt die Oberklasse NSObject bereit, die Unterklassen überschreiben dürfen.

Mit NSLog können Sie also zur Laufzeit beliebige Texte in die Konsole schreiben. Sie können diese Funktion allerdings auch dazu benutzen, sich interessante Variablenwerte ausgeben zu lassen; sie ist somit eine einfache Möglichkeit, die Variablen zur Laufzeit zu überprüfen. Xcode zeigt Ihnen allerdings nicht nur die Log-Ausgaben an, sondern die App speichert sie auch in einer Log-Datei, und Sie können sie über den Organizer, wie oben beschrieben, ansehen.

3.6.2Der Debugger

Obwohl Xcode schon recht viele Fehler findet, kann Ihr Programm natürlich trotzdem noch weitere Fehler, sogenannte Laufzeitfehler, enthalten. Wie der Name schon sagt, treten diese Fehler erst bei der Ausführung des Programms auf, sind leider nicht immer offensichtlich und manchmal nur sehr schwer zu finden. Bei der Verwendung von Threads kann die Fehlersuche sogar zu vorzeitiger Alterung, Haarausfall und schlechtem Atem führen. Mit steigender Programmkomplexität wird das Printf-Debugging über Log-Ausgaben auch zunehmend unbequemer.

Laufzeitfehler lassen sich in der Regel am einfachsten über einen Debugger aufspüren. Damit können Sie Ihr Programm während der Ausführung anhalten, Variablen inspizieren und gegebenenfalls verändern. Sie können das Programm entweder durch einen Pause-Knopf oder durch Haltepunkte (Breakpoints) anhalten und danach die Ausführung schrittweise oder kontinuierlich fortsetzen. Außerdem lassen sich die Breakpoints an Bedingungen knüpfen, was besonders bei Schleifen und anderen wiederholt aufgerufenen Anweisungen hilfreich ist.

Das Setzen eines Breakpoints ist einfach: Klicken Sie in die graue Leiste links neben Ihrem Quelltext. Es erscheint ein blaugrauer Pfeil, der den Breakpoint symbolisiert (siehe Abbildung 3.87). Der Debugger stoppt dann an dieser Stelle oder an der ersten Anweisung nach dieser Stelle, wenn Sie den Haltepunkt in eine Zeile gesetzt haben, in der keine Anweisung steht. Durch einen Rechtsklick auf das Breakpoints-Symbol und die Auswahl des entsprechenden Menüpunkts können Sie den Breakpoint wieder entfernen. Alternativ verwenden Sie den Breakpoint-Navigator (+) dazu oder ziehen den Haltepunkt wieder aus der Leiste. Außerdem erlaubt Xcode Ihnen das Verschieben der Breakpoints in der Leiste.

Abbildung 3.87 Setzen eines Breakpoints

Wenn der Debugger anhält, zeigt er einen grünen Pfeil links neben dem Quelltext an, der die aktuelle Ausführungsposition darstellt (siehe Abbildung 3.88). Der Debugger hat allerdings die Anweisung an dieser Position noch nicht ausgeführt.

Sie können sich während des Halts die aktuellen Variablenwerte ansehen und sie durch einen Doppelklick auf die betreffende Zeile ändern. Das funktioniert jedoch leider nur bei Variablen mit einfachen Datentypen (wie z. B. int, double). Bei Zeigern auf Objekte können Sie so lediglich den Zeiger verbiegen (z. B. auf 0 also nil setzen).

Abbildung 3.88 Halt des Programms an einem Breakpoint

Außerdem haben Sie über die Steuerungsleiste des Debuggers (siehe Abbildung 3.89, von links nach rechts) folgende Möglichkeiten:

• Blenden Sie den Debugger-Bereich ein oder aus.
• Deaktivieren und Aktivieren Sie alle Breakpoints auf einmal. Xcode stellt deaktivierte Breakpoints in einem helleren Blauton als aktivierte dar.
• Sie lassen die Ausführung bis zum nächsten Breakpoint oder einem manuellen Halt fortfahren. Während Ihr Programm läuft, zeigt der Debugger statt des Fortfahren- ein Pause-Symbol, mit dem Sie die Ausführung anhalten können.
• Führen Sie nur die nächste Anweisung aus. Durch mehrfaches Anklicken dieses Symbols können Sie Ihr Programm schrittweise ausführen.
• Falls der Debugger vor einem Methodenaufruf angehalten hat, können Sie ihn dort hineinspringen lassen. Das funktioniert allerdings nur, wenn dazu auch die entsprechenden Debugging-Symbole vorhanden sind. Das ist bei den Systembibliotheken in der Regel nicht der Fall. Ansonsten verhält sich diese Funktion wie das schrittweise Ausführen.
• Analog können Sie auch aus einer Methode herausspringen. Der Debugger läuft dabei so lange weiter, bis er die aktuelle Methode verlässt. Das funktioniert auch, wenn das Betriebssystem oder eine Programmbibliothek diese Methode aufgerufen hat. Sie bekommen dann statt Objective-C-Quellcode Assembler-Anweisungen zu sehen.
• Die Steuerungsleiste zeigt Ihnen den aktuellen Thread an, in dem sich das Programm gerade befindet. Über eine Liste können Sie auch die anderen Threads auswählen und ansehen.
• Außerdem zeigt die Steuerleiste Ihnen die oberste Methode beziehungsweise Funktion des Stapels des ausgewählten Threads an. Durch Anklicken können Sie sich die anderen Methoden und Funktionen auf dem Stapel ansehen und in diese wechseln.

Abbildung 3.89 Steuerungsleiste des Debuggers

Die Funktionsweise des Debuggers werden wir jetzt anhand des Beispielprojekts verdeutlichen. Setzen Sie dazu einen Breakpoint in die erste Zeile der Action-Methode updateViews in der Klasse AlarmClockViewController, und starten Sie die App über Xcode. Der Simulator öffnet das Programm, und der Debugger stoppt die Ausführung in der ersten Zeile dieser Methode.

Die Variablenansicht, die sich unter der Steuerleiste des Debuggers befindet, zeigt unter anderem das Symbol self mit einem Dreieck zum Aufklappen an. Wenn Sie es aufklappen, finden Sie die Attribute des Viewcontrollers und eine Zeile mit dem Namen UIViewController. Unter dieser Zeile befinden sich die Daten der Oberklasse des Objekts. Sie können die Attribute und das Symbol für die Oberklasse aufklappen und sich auch dort die enthaltenen Attribute ansehen.

Wenn Sie den Debug-Navigator über + öffnen, können Sie sich die Aufrufstapel der einzelnen Threads des Programms ansehen (siehe Abbildung 3.90). Das Programm hat die Methode updateViews im Hauptthread aufgerufen, was Sie am untersten Symbol – der Funktion main – sehen. Der Aufrufer der Methode ist die Methode viewWillAppear:. Wenn Sie die Methode anklicken, springt Xcode in der Methode viewWillAppear: an die Stelle des Aufrufs, also die letzte Zeile (siehe Listing 3.60). Außerdem zeigt Xcode in der Variablenansicht die Variablen der Methode viewWillAppear: an; das ist zum einen self und zum anderen der Parameter inAnimated.

Abbildung 3.90 Der Debug-Navigator von Xcode

Klicken Sie jetzt in der Steuerungsleiste des Debuggers auf das Symbol, um die nächste Anweisung auszuführen. Der grüne Pfeil springt zur nächsten Zeile, und in der Variablenansicht ändert sich der Wert der Variablen theApplication. Danach klicken Sie mehrmals auf das Symbol, bis der Programmzeiger in der letzten Zeile der Methode mit der Anweisung [self updateTimeLabel]; steht. Bei der schrittweisen Ausführung des Codes ist Ihnen sicherlich aufgefallen, dass der Debugger nur einen Block der Bedingung durchlaufen hat. Welchen Block die App durchläuft, hängt natürlich vom Benachrichtigungsobjekt in der Methode ab.

Springen Sie mit dem Debugger jetzt in die Methode updateTimeLabel, indem Sie auf das Symbol zum Hineinspringen in eine Methode klicken. Der Debugger hält in der ersten Zeile der Methode updateTimeLabel. Wenn Sie das Symbol zum Verlassen der Methode anklicken, springt der grüne Pfeil in die Zeile mit der letzten schließenden geschweiften Klammer der Methode updateViews.

3.6.3Breakpoints verwalten

Sie können nicht nur alle Breakpoints auf einmal deaktivieren oder aktivieren, sondern auch einzeln. Dazu klicken Sie den Breakpoint in der Leiste einmal an, so dass Xcode ihn in einem helleren Blau darstellt. Durch erneutes Anklicken aktivieren Sie ihn wieder.

Das erreichen Sie auch durch Anklicken der Breakpoint-Symbole im Breakpoint-Navigator (siehe Abbildung 3.91), über den Sie auch Exception-Breakpoints setzen können. Der Debugger löst einen Exception-Breakpoint immer dann aus, wenn die App eine Ausnahme wirft. Objective-C verfügt zwar über einen ähnlichen Ausnahme-Mechanismus wie andere Programmiersprachen (z. B. C++ oder Java), allerdings hat sich hier die Ausnahmebehandlung bei weitem nicht so stark durchgesetzt.

id theDelegate = [[UIApplication sharedApplication] delegate];
NSLog(@"intValue: %d", [theDelegate intValue]);

@throw [NSException exceptionWithName:...];

Exception-Breakpoints aktivieren Sie im Breakpoint-Navigator über den Plus-Button am unteren Rand und die Auswahl des Punktes Add Exception Breakpoint... (siehe Abbildung 3.91).

Abbildung 3.91 Aktivieren des Exception-Breakpoints

Um den Breakpoint zu testen, fügen Sie die beiden Zeilen

id theDelegate = [[UIApplication sharedApplication] delegate];
NSLog(@"intValue: %d", [theDelegate intValue]);

in die Methode viewWillAppear: der Klasse AlarmClockViewController ein und führen die App aus.

Wenn Sie vorher den Exception-Breakpoint aktiviert haben, stoppt der Debugger in dieser Methode in der Anweisung mit dem NSLog-Aufruf, und in der Variablenansicht können Sie sich die Variablenwerte ansehen. Bei einer realen Ausnahme können Sie damit die Variablenwerte untersuchen, um festzustellen, was die Ausnahme verursacht hat; in der Regel hat der Nachrichtenempfänger nicht die erwartete Klasse.

Als Nächstes deaktivieren Sie den Exception-Breakpoint über den Breakpoint-Navigator und führen das Programm erneut aus. Diesmal stoppt der Debugger in der Funktion main an der Aufrufstelle der Funktion UIApplicationMain in der Datei main.m. An dieser Stelle sehen Sie nicht die Methode und ihre Variablen und können den Programmabsturz deshalb nicht genauer analysieren.

3.6.4Die Debugger-Konsole

Der Debugger in Xcode basiert auf dem Kommandozeilenprogramm lldb. Xcode wandelt alle bisher besprochenen Anweisungen an den Debugger (z. B. zum Setzen eines Breakpoints mit der Maus) in die entsprechenden Debuggerbefehle um. Diese grafische Steuerung des Debuggers ist zwar sehr praktisch, allerdings nicht immer ausreichend. Über die Debuggeransicht haben Sie auch Zugriff auf die Debugger-Konsole (siehe Abbildung 3.88, unten rechts), die Sie auch über ++ öffnen können. Mit den drei Buttons über der Ansicht stellen Sie ein, ob Sie nur die Variablenansicht, die Debugger-Konsole oder beide Ansichten sehen möchten. In der Debugger-Konsole finden Sie alle Log-Ausgaben Ihrer App und auch alle Ausgaben des Debuggers. Außerdem können Sie hinter dem Prompt (lldb) Befehle für den Debugger eingeben.

Der Debugger besitzt einen sehr großen Befehlsumfang, dessen vollständige Beschreibung den Rahmen dieses Buches sprengen würde, weswegen dieser Abschnitt nur die wichtigsten Befehle behandelt. Sie können jedoch sehr viele Befehle über die GUI-Einbindung in Xcode ausführen, und viele Befehle brauchen Sie auch eher selten. Glücklicherweise besitzt der Debugger zudem eine eingebaute Hilfe, mit der Sie schnell jeden beliebigen Befehl nachschlagen können. Sie rufen die Hilfe über das Kommando help auf, worauf lldb mit den vorhandenen Hilfekategorien antwortet.

Hinter das Hilfekommando können Sie den Namen einer Kategorie oder eines Kommandos schreiben. Dann zeigt Ihnen der Debugger die Hilfe zu dieser Kategorie beziehungsweise zu diesem Kommando an. Wenn Sie beispielsweise help help eingeben, sehen Sie den Hilfetext zum Kommando help.

Ablaufsteuerung

Über die Debugger-Konsole steuern Sie die Ausführung Ihrer App. Nach dem Halt an einem Breakpoint können Sie das Programm über den Befehl continue oder c weiterlaufen lassen. Dieses Kommando akzeptiert eine Zahl als optionales Argument. Die Zahl gibt an, wie oft der Debugger diesen Breakpoint erreichen muss, damit er wieder daran anhält. Wenn Sie also c 4 eingeben, dann ignoriert der Debugger dreimal diesen Breakpoint und stoppt erst beim vierten Mal.

Über das Kommando step oder kurz s weisen Sie den Debugger an, die aktuelle Anweisung auszuführen. Falls das ein Funktions- oder Methodenaufruf ist, springt der Debugger da hinein. Auch diesem Kommando können Sie über ein optionales Argument mitteilen, wie oft der Debugger es ausführen soll. Beispielsweise führt der Debugger mit dem Kommando s 4 die vier nächsten Anweisungen aus.

Analog zu step funktioniert das Kommando next oder n, außer dass es keine Subroutinen anspringt. Mit next können Sie also Methoden- oder Funktionsaufrufe einfach überspringen. Auch bei diesem Befehl können Sie wieder durch ein optionales Argument angeben, wie oft der Debugger ihn ausführen soll.

Die aktuelle Funktion oder Methode verlassen Sie über den Befehl finish oder fin. Der Debugger lässt dann das Programm so lange weiterlaufen, bis es die aktuelle Methode oder Funktion beendet hat. Wenn Sie den Debugger beispielsweise an einem Breakpoint in der Klasse drawClockHands anhalten lassen und den Befehl fin eingeben, springt der Programmzeiger ans Ende der drawRect:-Methode hinter die Anweisung [self drawClockHands].

Datenausgabe

Die am häufigsten verwendeten Kommandos sind wahrscheinlich print-object und print, die Sie aufgrund ihrer häufigen Verwendung auch mit po beziehungsweise p abkürzen können. Beide Befehle dienen dazu, Programmdaten auszugeben, wobei Sie hinter den Befehl einen Objective-C-Ausdruck schreiben müssen.

Mit print-object können Sie ein Objective-C-Objekt ausgeben. Wenn Sie beispielsweise einen Breakpoint in die Methode viewDidLoad wie in Abbildung 3.92 setzen und nach dem Halt des Programms an dieser Stelle den Befehl po self oder alternativ print-object self eingeben, erhalten Sie ungefähr die Ausgabe <AlarmClockViewController: 0x79935e0>. Dabei kann die hexadezimale Zahl 0x79935e0 am Ende abweichen, weil sie die Speicheradresse des Objekts angibt, die sich bei jedem Programmlauf ändern kann. Sie können auch kompliziertere Ausdrücke verwenden und sich beispielsweise mit po [[self timeLabel] text] den Wert des Labels für die Anzeige der Alarmzeit ausgeben lassen. Hier dürfen Sie auch die Punktnotation verwenden; der Befehl po self.timeLabel.text führt also zur gleichen Ausgabe.

Abbildung 3.92 Ausgabe von Objekten in der Debugger-Konsole

Für die Textausgabe eines Objekts in der Konsole muss der Debugger das Objekt in eine Zeichenkette umwandeln, sofern es nicht bereits eine ist. Dazu verwendet er die Methode description des Objekts. Sie können diese Methode also überschreiben, um die Ausgabe im Debugger anzupassen. Für die Klasse AlarmClockViewController können Sie die Methode aus Listing 3.74 verwenden. Dann gibt Ihnen der Debugger die eingestellte Alarmzeit und den Zustand des Alarmschalters aus.

- (NSString *)description {
    return [NSString stringWithFormat:@"alarm: %@ (%@)", 
        self.timeLabel.text, 
        self.alarmHidden ? @"off" : @"on"];
}

Listing 3.74 Anpassung der Debuggerausgabe

Wenn Sie den Alarm einschalten und beim Halt des Debuggers in der Methode switchAlarm: den Befehl po self in der Konsole eingeben, erhalten Sie jetzt die Ausgabe alarm: 4:40 (on), wobei natürlich die Alarmzeit von Ihrer Auswahl abhängt.

Die Methode description dient ja auch in anderen Situationen dazu, Objekte in adäquate Zeichenketten umzuwandeln. Wenn Sie im Debugger einen anderen Text ausgeben wollen, als das die Methode description macht, können Sie auch die Methode debugDescription überschreiben, die standardmäßig das Ergebnis des Methodenaufrufs von description zurückgibt.

Die Implementierung von debugDescription in Listing 3.75 gibt zusätzlich zur Methode description die Zeit des Clock-Controls in Sekunden aus.

- (NSString *)debugDescription {
    return [NSString stringWithFormat: 
        @"debug alarm: %@ (%.3fs, %@)", 
        self.timeLabel.text, self.clockControl.time, 
        self.alarmHidden ? @"off" : @"on"];
}

Listing 3.75 Zeichenkette für Debug-Ausgabe bereitstellen

Wenn Sie diese Methode in die Klasse AlarmClockViewController einfügen und bei einem Breakpoint das Kommando po self eingeben, antwortet der Debugger mit einer Meldung in der Form debug alarm: 4:40 (16803.488s, on). Das Kommando po [self description] führt hingegen nach wie vor zur Ausgabe von alarm: 4:40 (on).

Über den Befehl print können Sie einfache und zusammengesetzte Datentypen ausgeben. Allerdings müssen Sie hierbei dem Debugger unter Umständen mitteilen, welchen Typ die Ausgabe hat. Um das an einem praktischen Beispiel zu sehen, setzen Sie einen Breakpoint in die Zeile mit der vierten Anweisung, CGContextSaveGState(theContext);, in der Methode drawRect: der Klasse ClockView und starten die Ausführung. Wenn der Debugger in dieser Zeile stoppt, können Sie sich den Wert der Variablen theRadius über das Kommando p theRadius anzeigen lassen. Vor dem Wert steht ein Dollarzeichen, gefolgt von einer fortlaufenden Nummer und einem Gleichheitszeichen, also beispielsweise: (GGFloat) $0 = 160. [Anm.: Die Nummer hinter dem Dollarzeichen hängt davon ab, wie oft Sie bereits den print-Befehl aufgerufen haben. Es ist also nicht schlimm, wenn in Ihrer Konsole eine andere Nummer steht.] Der Debugger merkt sich die ausgegebenen Werte in internen Variablen, die Sie sich jederzeit über print wieder ausgeben lassen können (z. B. mit p $0). Sie können diese Variablen sogar in Ausdrücken verwenden und damit rechnen (z. B. p 2 * $0 + 20).

Das klappt auch mit der Struktur theBounds und dem Befehl p theBounds. Die Ausgabe sieht mit einem iPhone 5 unter iOS 7 beziehungsweise im entsprechenden Simulator so aus: (CGRect) $0 = origin=(x=0, y=0) size=(width=320, height=320). Auf anderen Gerätetypen weichen unter Umständen die Werte für width und height davon ab. Der Debugger gibt Ihnen also schön die Werte in der Struktur aus. Wenn Sie sich den Frame des Views ausgeben lassen wollen und p [self frame] eingeben, antwortet Ihnen der Debugger hingegen mit der Fehlermeldung:

error: 'frame' has unknown return type;

cast the call to its declared return type

error: 1 errors parsing expression

Das liegt daran, dass der Debugger nicht den Rückgabetyp der Methode frame ermitteln kann. Sie können ihm jedoch mit einem Typecast auf die Sprünge helfen. Wenn Sie p (CGRect)[self frame] eingeben, erhalten Sie die Ausgabe: (CGRect) $1 = origin=(x=0, y=0) size=(width=320, height=320)

Automatische Ausgaben

Beim Debuggen tritt häufig der Fall auf, dass Sie das Programm an einem bestimmten Breakpoint halten lassen, um sich den Wert bestimmter Variablen anzusehen. Beispielsweise möchten Sie jedes Mal, wenn die Ausführung in drawRect: stoppt, den Wert der Variablen theRadius sehen. Natürlich können Sie nach jedem Halt p theRadius aufrufen, was allerdings auf die Dauer sehr unbequem ist. Stattdessen können Sie auch den Befehl display mit einem Ausdruck als Argument verwenden. Wenn Sie den Befehl display theRadius eingeben, antwortet Ihnen der Debugger mit Stop hook #1 added. Jedes Mal, wenn er diesen Breakpoint erreicht, gibt er Ihnen von nun an den Wert der Variablen theRadius aus. Sie können auch mehrere automatische Ausgaben an einem Breakpoint machen. Dazu brauchen Sie nur entsprechend weitere display-Befehle abzusetzen. Wenn Sie mit dem Befehl display theBounds eine weitere automatische Ausgabe anlegen, gibt Ihnen der Debugger bei jedem Halt an diesem Breakpoint die Werte dieser beiden Variablen aus.

Sie können diese Ausgabe auch ohne Konsole erreichen, indem Sie in dem Kontextmenü des Breakpoints den Punkt Edit Breakpoint... aufrufen und in dem Pop-over-Dialog den Button Add Action anklicken. Für den Punkt Action wählen Sie den Eintrag Debugger Command aus, und in das Eingabefeld geben Sie das Kommando p theRadius wie in Abbildung 3.93 ein. Wenn der Debugger nun an diesem Breakpoint hält, gibt er immer den Wert dieser Variablen automatisch aus. Sie können weitere Befehle hinzufügen, indem Sie auf den Plus-Button klicken. Über die Option Automatically continue after evaluating weisen Sie den Debugger an, dass er nach der Aktion automatisch mit der Ausführung des Programms fortfährt.

Abbildung 3.93 Debugger-Kommando automatisch ausführen

Über den Befehl target stop-hook list erhalten Sie eine Liste aller automatischen Ausgaben, die Sie über den display-Befehl angelegt haben. Nach den zwei display-Kommandos von oben erhalten Sie die folgende Ausgabe:

Hook: 1

State: enabled

Commands:

expr -- theRadius

Hook: 2

State: enabled

Commands:

expr -- theBounds

Die erste Zeile jedes Hooks enthält die Nummer der Ausgabe und die dritte den Ausdruck, den Sie im display-Befehl angegeben haben. In der zweiten Zeile sehen Sie, ob die Ausgabe aktiv (enabled) oder inaktiv (disabled) ist.

Über den Befehl undisplay lässt sich die automatische Ausgabe eines Ausdrucks stoppen. Wenn Sie nur eine Ausgabe löschen wollen, müssen Sie die Zahl, die am Anfang der Ausgabe steht, als Argument angeben. Sie können also die Ausgabe von theResult durch den Befehl undisplay 1 wieder unterdrücken.

Wenn Sie die Ausgabe eines Ausdrucks nur temporär unterdrücken möchten, können Sie ihn über den Befehl target stop-hook disable und die Angabe der Nummer deaktivieren. Mit dem Befehl target stop-hook disable 2 deaktivieren Sie beispielsweise die Ausgabe der Variablen theBounds. Analog erlaubt Ihnen der Befehlteil enable, eine deaktivierte Ausgabe wieder zu aktivieren. Das heißt, mit target stop-hook enable 2 schalten Sie die automatische Ausgabe dieser Variablen wieder ein.

Werte verändern

Der Debugger erlaubt jedoch nicht nur die Anzeige, sondern auch die Veränderung von Variablenwerten. Sie können damit beispielsweise ausprobieren, wie sich Ihr Code mit anderen Werten verhält. Um einen Wert in der Debugger-Konsole zu setzen, verwenden Sie den Befehl expression mit einer gewöhnlichen Zuweisung in Objective-C-Syntax. Zum Beispiel können Sie über expression theRadius = 200 den Wert der Variablen theRadius in der Methode drawRect: verändern. Das geht auch mit den Attributen in einer Struktur, wie beispielsweise expression theBounds.position.x = 10.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.