iOS-Debugging: Die Sache mit den „unerklärlichen“ App-Crashs

Mit der Veröffentlichung des iOS 5 SDKs hat auch Apples Entwicklungsumgebung Xcode einen großen Versionssprung bekommen (von 3.x auf 4.x). Es kamen viele neue Features hinzu, ein neuer Compiler, ein neuer Linker, ein neuer Debbuger, usw. Bis der geneigte Entwickler alle Neuerungen entdeckt und seinen Entwickkungsprozess sicher nutzen kann, vergehen i.d.R. einige Wochen/Monate.

Eine Neuerung/Änderung fällt jedoch relativ schnell auf, wenn man sich mit einem unerklärlichen App-Crash beschäftigt. So gibt der aktuelle Debugger (aktuelles XCode 4.2.x) in seiner Standard-Konfiguration relativ spärliche Informationen zu einer Fehlerursache preis, der als (in einer von vielen Entwicklern zurecht gehassten 😉 Signal-Abortion)  „SIGABRT“ in der App-Einstiegsdatei main.m (main()-Funktion) auf sich aufmerksam macht.

Debugging

Ab und zu bekommt man in der Logging-Konsole einige kleine Hinweise über die Fehlerursache ausgegeben, wie z.B.:

App[96782:fb03] Uncaught exception: NSRangeException

App[96782:fb03] reason: *** -[__NSArrayI objectAtIndex:]: index 0 beyond bounds for empty array

Doch nicht selten findet man dort keine verwertbaren bis garkeine Informationen zur Fehlerursache. Auch die Frage wo im eigenen Programmcode der Fehler auftritt bleibt unbeantwortet.

Mit folgenden kleinen Code-Ergänzungen in der main.m Datei des iOS-App-Projektes passiert ein kleines Wunder ;):

Der selbe App-Sturz von oben gibt in der Logging-Konsole diesmal viel mehr Informationen preis, wie beispielsweise die relevante fehlerverursachende Stelle im eigenen Source-Code (Klassenname und Methodenname).

Exceptions

Sind wir jetzt zufrieden?! Einige bestimmt, andere wollen es sicher noch genauer wissen. So kann ein Projekt aus vielen hunderten Klassen bestehen und somit die Suche nach dem Ort der Ursache trotzdem umständlich sein. Doch auch dafür gibt es einen „Trick“. Durch die folgenden 2 Schritte  („+/Add Exception Breakpoint“)in der Breakpoint-Ansicht des Projektes sorgen alle geworfenen Exceptions automatisch dafür, dass der Debugger sofort an die „Unglückstelle“ im Source-Code springt:

Exceptions

Exceptions

So, jetzt sind wir zufrieden und können getrost alle ungelösten Mysterien der App-Crashs nach und nach aufgedecken und beheben.

Eines muss jedoch bedacht werden. Exceptions sind in der iOS-Entwicklung (oder generell bei Objective-C/Cocoa/Touch) kein Instrument des Errorhandlings, wie es beispielsweise in der Java-Entwicklung zu den tagtäglichen try-catch-Maßnahmen gehört. Exceptions repräsentieren hier grobe (zu lösende) Programmierfehler und sorgen i.d.R. für Memory-Leaks und unvorhergesehene Sprünge im Call-Stack und weitere undeterministische semanische Verhaltensweisen bei Versuchen der Wiederaufname des „normalen“ Programmflusses (catch/finally). Für das „geführte“ Errorhandling sind in den iOS-APIs NSError-Objekte der empfohlene richtige Weg!

Die oben genannten Schritte zur Aufspürung der Ursachen und Orte von App-Crashs sind primär für die Entwickkungszeit einer iOS-App gedacht. Somit ist es zu empfehlen diese Maßnahmen gleich nach Anlegen eines neuen iOS-Projektes einzurichten, um frühzeitig Transparenz zu den potentiell auftretenden Fehlern zu bekommen.

Bewerte diesen Beitrag
0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

  Newsletter abonnieren (Jederzeit wieder abbestellbar)