Boehrsi.de - Blog

Eine App sollte keine Crashes produzieren. Diese Aussage ist denke ich für jeden erfassbar und verständlich. Um dies zu erreichen programmiert man natürlich sicher und effektiv. Doch hin und wieder kommt dann doch ein Crash rein und man muss ihn fixen. Doch reicht ein Guard um Crashes / Bugs wirklich zu beheben? Von Zeit zu Zeit sicherlich, doch dies hängt natürlich von der Situation ab und oft ist selbige durchaus komplexer und bedarf etwas mehr Zuwendung. Mit Guard ist in diesem Kontext z.B. ein null Check gemeint, welcher einen Code-Block vor Ausführung schützt.

Das Problem ist, dass ein Guard zwar der Crash der App verhindern kann, was durchaus gut ist, allerdings auch die App in einem falschen Zustand hinterlassen kann. So kann es passieren, dass eine View null ist, obwohl sie dies nicht sollte. Hier kann man nun einen Guard einfügen und alles scheint gut. Doch was ist wenn die darunterliegenden Strukturen aus dieser View Daten brauchen, die z.B. beim Wiederherstellen selbiger aus dem Bundle geladen werden und dies zum Zugriffszeitpunkt einfach noch nicht abgeschlossen war? Dann hat man eine View mit falschen Daten und alle folgenden Aktionen können fehlschlagen. Im schlimmsten Fall verursacht dies im Laufe der Zeit mehr Fehler, welche wiederum mehr Guards bekommen, sodass man das Problem immer weiter verschleiert. Um gegen diese Art von Problemen vorzugehen gibt es leider nur eine Methode. Backtracking der Probleme, bis zum wirklichen Problem. Symptome zu beheben ist das Ziel, doch dafür muss man die Quelle selbiger entdecken. Ansonsten hat man irgendwann einen Flickenteppich, der zum einen oder anderen Zeitpunkt auseinanderfallen kann. Passiert dies, dauert es unter Umständen sehr lange die eigentlichen Fehler zu finden und zu beheben. Insgesamt kann man also einiges an Zeit und vermutlich auch Aufwand sparen, wenn man versucht die Probleme direkt von Anfang an komplett zu beheben und nicht nur notdürftig zu flicken.