Kapitel 2: Grundlagen / 2.9 Optionals

Haben wir mit Tupeln bereits eine Swift-Spezialität besprochen, kommen wir mit Optionals nun in den Gourmet-Bereich:

Da das Konzept von Optionals etwas komplizierter ist als das, was wir bisher besprochen haben, will ich ein wenig ausholen, um das Problem zu erklären, dass Optionals zu lösen versuchen:

In vielen Programmiersprachen können Variablen- oder Konstanten einerseits einen Wert enthalten, der ihrem Typ entspricht oder stattdessen keinen Wert (jedenfalls dann, wenn man die Objekt-Varianten der Datentypen wählt).

Enthält beispielsweise ein Integer-Objekt keinen Wert, dann enthält es in Java den Wert null und in Objective C den Wert nil. Dies gilt in beiden Sprachen für jeden Objekttyp: Ein String-Objekt kann null bzw. nil sein, genauso wie ein Integer- oder Fließkomma-Objekt.

Dies bringt ein Problem mit sich: Will ich in Java zum Beispiel einen String komplett in Großbuchstaben umwandeln, muss ich zunächst prüfen, ob er nicht vielleicht null ist. Denn ist er null und ich versuche die Umwandlung, führt das zu einer Runtime Exception und mein Programm stürzt ab. Dies hat in der Praxis zur Folge, dass Java Code an vielen Stellen durch if und else Zweige regelrecht aufgebläht ist, um ein um’s andere Objekt zunächst auf null zu prüfen und erst dann damit zu arbeiten. Manche Programmierer lassen diese Prüferei sein, bekommen dafür lesbareren Code, aber handelt sich fiese Abstürze an Stellen ein, die kein Tester je hatte erahnen können – das ist also auch keine Lösung.

Objective-C hat dasselbe Problem, geht aber anders damit um: Ist ein String nil und ich versuche ihn in Großbuchstaben umzuwandeln, geschieht.. nichts: Das Ergebnis des Umwandlung bleibt nil, so als hätte ich gar nichts gemacht. Lässt man nun in Objective-C das aufblähende Prüfen auf nil sein, bekommt man zwar keine Runtime Exceptions, aber im ungünstigen Fall einen undefinierten Zustand der Applikation, da irgendwann niemand mehr weiß, welche Variable überhaupt noch etwas enthält.

Ich persönlich – und das ist unter Programmierern leider keine Mehrheitsmeinung – halte einen undefinierten Zustand der Appliktion tatsächlich für deutlich schlimmer als bisher unentdeckte Runtime Exceptions, da bei letzteren Fehler wenigstens auffallen – und sei es erst beim Kunden. Viele Programmierer – oder besser gesagt deren Projektleiter oder die kommerziell Verantwortlichen – halten einen Programmabsturz beim Kunden für den schlimmsten anzunehmenden Unfall.

Aber stellen Sie sich vor, sie haben ein Programm zur Berechnung Ihrer Einkommensteuer gekauft und das enthält einen Fehler, weil ein Programmierer von den vielen if-Abfragen genervt war. Dann ist es doch besser, das Programm stürzt ab und Sie ärgern sich, als dass das Programm zwar nicht abstürzt, aber dafür falsche Ergebnisse liefert, so dass Sie falsche Zahlen an das Finanzamt liefern.

Das Problem mit nil und null ist also klar und es ist ein reales, alltägliches Problem, nicht nur ein theoretisches. Und weil auch Apple den Umgang mit nil in Objective-C nicht besonders toll fand, haben die Swift-Entwickler ein neues, ein drittes Konzept entwickelt, die Optionals.

Kapitel 2.9: Optionals

Schreibe einen Kommentar

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