Boehrsi.de - IT und Gaming Blog

Es ist schon wieder etwas her das ich eine News in diesem Bereich geschrieben habe, doch nun wird’s mal wieder Zeit. Denn aktuell grübele ich bezüglich einem Thema, bei welchem ich nicht zu einem optimalen Entschluss komme. Es geht um die Menge der zu verwendenden Guards bzw. Sicherheitsmechanismen, um eine fehlerfreie User Experience zu gewährleisten.
Generell sind wir Softwarenentwickler uns bestimmt einig, dass das User Interface und alles was der Nutzer darin zu sehen bekommt, eher robust sein sollte und entsprechend Fehler gut abfangen muss. Doch wie weit soll man gehen, wenn es darum geht die UI und Logik gegen fehlerhafte APIs zu schützen, die man selber mehr oder weniger unter Kontrolle hat. Ich rede hier von Schnittstellen die auf dem Gerät in Form von Bibliotheken vorhanden sind, nicht von externen APIs, die z.B. auf entfernten Servern liegen (letztere sollten definitiv umfangreich und effektiv abgesichert werdern). Denn auch selbstverwaltete Bibliotheken, welche vielleicht von einem Kollegen der aktuell keine Zeit hat gepflegt werden, können hin und wieder Fehler beinhalten.
Ich bin ein Fan von Fail Fast & Fail Often, denn meiner Meinung nach gehen ansonsten zu viele Fehler unter. Doch wie geht man mit mehr oder weniger bekannten Issues um, welche in darunterliegenden Ebenen vorhanden sind, die teilweise zum eigenen Code gehören.
Baut man Guards ein - vielleicht auch nur temporär - können selbige in Vergessenheit geraten und später das Debugging massiv erschweren. Lässt man die Fehler zu, kann es zu sichtbaren UI Fehlern kommen, was natürlich zu vermeiden ist. Ich persönlich sehe hier eine Zwickmühle, welche ich zwar nicht perfekt, aber für mich für den Moment passend lösen konnte.

Für ein konkretes Problem, welches die App für den Nutzer in einen fehlerhaften Zustand bugsierte, habe ich das generelle Error Handling erweitert. Soll heißen Fehler werden - sofern non-recoverable - abgefangen und die UI entsprechend korrigiert. Darüber hinaus erfolgt umfangreiches Logging, sodass das Debugging sowohl während der Entwicklung, wie auch nach der Auslieferung möglich ist. Im Prinzip akzeptiere ich als Entwickler den Fehler und logge ihn mit der ohnehin vorhandenen Infrastruktur, verhindere dass der Nutzer dadurch blockiert wird, verschleiere das Problem aber nicht.
Es bleibt ein fader Beigeschmack, denn man weiß das die Logs mitunter gut gefüllt sein werden, aber leere Logs und entsprechend auch weniger Informationen machen das Ganze auch nicht besser. Alles in allem und während ich diesen Beitrag schreibe und noch einmal über das Handling nachdenke, bin ich eigentlich doch ganz zufrieden. Mich würde allerdings interessieren wie ihr mit derartigen Problemen umgeht.