Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Railway Oriented Programming - Funktionaler programmieren ohne Exceptions
- 1. Funktionaler programmieren ohne Exceptions Railway Oriented Programming
- 2. Exceptions sind schlimmer als GOTOs. JOELSPOLSKY CEO Stack Exchange Network Betsy Weber - Joel Spolsky - flickr.com/photos/betsyweber/8044869747 CC Attribution 2.0 Generic - creativecommons.org/licenses/by/2.0/ Quelle: https://www.joelonsoftware.com/2003/10/13/13/
- 6. Tomwang112 - Copyright 2011 - www.istockphoto.com/fotos/113592506
- 8. Alexas_Fotos - CC0 Public Domain - pixabay.com/de/sprung-new-york-gefährlich-verrückt-2040426/
- 12. Die null-Referenz: Mein Milliarden- Dollar-Fehler. TONYHOARE Informatik-Pionier Rama - Sir Charles Antony Richard Hoare giving a talk at the EPFL on 20th of June 2011 commons.wikimedia.org/wiki/File:Sir_Tony_Hoare_IMG_5125.jpg - CC BY-SA 2.0 FR - creativecommons.org/licenses/by-sa/2.0/fr/ Quelle: https://www.infoq.com/presentations/ Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
- 20. obpia30 - CC0 Public Domain - pixabay.com/de/katze-box-predator-650770/
- 21. obpia30 - CC0 Public Domain - pixabay.com/de/katze-box-predator-650770/
- 24. quimono - CC0 Public Domain - pixabay.com/de/wasser-tröpfchen-tropfen-spritzen-1281247/
- 27. Katie Tegtmeyer - Crossed fingers I - flickr.com/photos/katietegtmeyer/124315323 CC Attribution 2.0 Generic - creativecommons.org/licenses/by/2.0/
- 32. Success Failure
- 37. eak_kkk - CC0 Public Domain - pixabay.com/de/wasserfall-wasser-spritzen-platsch-1049079/
- 39. Arcaion - CC0 Public Domain - pixabay.com/de/die-pille-kapsel-medizin-1772275/
- 40. onSuccess()
- 41. onSuccess()
- 42. onSuccess()
- 43. ensure()
- 44. ensure()
- 45. ensure() true
- 47. map()
- 48. map()
- 49. map()
- 50. map() ok
- 51. map() ok Fehler
- 52. (alle)
- 53. (alle)
- 68. pvdv63 - CC0 Public Domain - pixabay.com/de/notbremse-gefahr-zug-blockiert-1053741/
- 69. PublicDomainPictures - CC0 Public Domain - pixabay.com/de/domino-dominosteine-spiel-spielen-21176/
- 70. Thomas Backa - WTF mug - CC0 Public Domain - flickr.com/photos/backa/4180780815/
- 72. obpia30 - CC0 Public Domain - pixabay.com/de/katze-box-predator-650770/ Monaden
- 76. Optional Wert vorhanden? null-Checks Stream mehrere Werte eigene Iteration Promise asynchrones Ergebnis eigene Threads
- 77. Optional Wert vorhanden? null-Checks Stream mehrere Werte eigene Iteration Promise asynchrones Ergebnis eigene Threads Result Ergebnis einer Aktion Exception Handling
- 81. 2) return() oder unit()
- 84. 3) bind(), >>= oder flatMap()
- 94. 1) Identität von rechts m >>= return = m 2) Identität von links return x >>= f = f x 3) Assoziativität (m >>= f) >>= g = m >>= (x . f x >>= g) Quelle: http://www.inf.fu-berlin.de/lehre/SS09/PI02/docs/monaden.pdf
- 96. ROP in der Praxis
- 102. WikiImages - CC0 Public Domain - pixabay.com/de/lochkartenlocher-datenverarbeitung-62897/
- 105. Fazit
Hinweis der Redaktion
- Ich möchte heute über eine etwas andere Art der Fehlerbehandlung sprechen: Programmierung ohne Exceptions. Doch warum sollte man auf Exceptions verzichten?
- Der Gründer von StackOverflow hat schon 2003 diese Aussage in einem Blogartikel getätigt.
- Joel Spolsky nennt zwei Punkte, die Exceptions zu „GOTOs“ werden lassen.
- Der erste Kritikpunkt ist, dass Exceptions im Code nicht sichtbar sind. Man kann nicht erkennen, ob eine Methode eine Exception wirft oder nicht.
- Hier ist weder ersichtlich, welche Methode eine Exception werfen kann, noch wohin der Code im Fehlerfall springt.
- Wie gut, dass es in Java Checked Exceptions gibt, nicht wahr?
- In diesem klassischen Beispiel für eine Exception ist sofort ersichtlich, welche Methoden einen Fehler provozieren könnten. Allerdings ist nur durch Nachverfolgung der kompletten Aufrufhierarchie der Codepunkt zu finden, zu dem im Fehlerfall gesprungen wird.
- Und das ist Spolskys zweiter Kritikpunkt: Es gibt zu viele Ausstiegspunkte aus der Methode. Und da Exceptions den normalen Kontrollfluss unterbrechen, werden Daten ggfs. in einem ungültigen Zustand hinterlassen oder Pfade durch den Code genommen, die nicht vorhersehbar sind.
- Wenn z.B. in der Aufrufhierarchie irgendwo ein weiteres Exception-Handling eingebaut wird, landet der Sprung auf einmal an einer ganz anderen Stelle. Das ist für den Entwickler schwer nachzuvollziehen.
- Man könnte auch einfach ein GOTO nutzen und wüsste wenigstens verlässlich, wohin gesprungen wird.
- Ok, Exceptions sind doof. Aber was können wir nun dagegen tun?
- Ein ähnlich schwerwiegendes Problem ist das Konzept von „null“. Java 8 bietet schon eine Lösung für das null-Problem.
- So sähe „normaler“ Code aus, der null prüft.
- Moderner Code verwendet kein null, sondern kennzeichnet durch Optional<T> explizit, dass evtl. kein Wert vorhanden ist. Allerdings hat man durch den hier gezeigten Aufbau nichts gewonnen…
- ...daher sollte man Optional<T> gleich so verwenden, wie es gedacht ist.
- Doch wie übertragen wir diese Idee nun auf das Exception-Handling?
- Indem wir eine Datenstruktur einführen, die einen möglichen Fehlerzustand explizit macht: das Result-Objekt. Und wie wir damit arbeiten, zeige ich nun in diesem Vortrag.
- Dazu habe ich heute drei Bereiche mitgebracht, über die ich sprechen möchte.
- Das Titelthema: Railway Oriented Programming.
- Was das Ganze mit Monaden zu tun hat.
- Und zum Schluss noch ein Praxisbeispiel.
- 7:00 Beginnen wir mit einem Überblick über die Idee hinter dem Railway Oriented Programming.
- Die Idee basiert auf der Fehlerbehandlung in der funktionalen Programmierung.
- Dort verwendet man gerne „reine“ Funktionen, die keine Seiteneffekte auslösen, sondern ausschließlich auf den hineingegebenen Werten arbeiten und ein Ergebnis liefern.
- Diese Methode wäre so eine „reine“ Funktion.
- Aber sobald die Methode eine Exception erzeugt, ändert sich alles. Sie ist nun nicht mehr rein, sondern erzeugt ggfs. einen anderen Ausgang, als von außen sichtbar ist.
- Kurzum: Die Methode „lügt“! Man erkennt von außen nicht mehr, dass es neben dem normalen Ausgang auch einen Fehlerfall geben kann. Und dieser zweite Weg müsste auch anders behandelt werden als der normale, nämlich mit try/catch.
- Um dies zu verhindern, kann man den potentiell fehlerhaften Ausgang der Methode explizit machen, indem man anstatt eine Exception zu werfen…
- …ein Ergebnis liefert, dass diesen Zustand kapselt: ein „Result“.
- Das Result-Objekt kann nun nach seinem Zustand gefragt werden, sodass darauf im aufrufenden Code reagiert werden kann. Aber dadurch hätte man nichts gewonnen. Genau wie bei Optional.isPresent().
- Und hier kommt das Railway Oriented Programming ins Spiel. Eine Fluent-API ermöglicht die weitere Programmierung ohne zu wissen, ob das Result fehlerhaft ist oder nicht. Die durchzuführenden Aktionen werden einfach verkettet und das Result-Objekt übernimmt die Steuerung, welche von ihnen tatsächlich ausgeführt werden.
- Das Result-Objekt hat zwei interne Zustände (fehlerhaft und erfolgreich), die unterschiedlich auf empfangene Nachrichten reagieren.
- Die mit onSuccess() übergebene Funktion wird nur im Zustand Success ausgeführt.
- Analog verhält sich onFailure() im Zustand Failure.
- Manchmal muss man Operationen auch unabhängig vom Zustand ausführen. Dafür ist onBoth() gedacht.
- So einfach sieht das dann im Code des Result-Objekts aus.
- Das allein reicht aber nicht, um die Aufrufe schön lesbar verketten zu können. Es muss eine Fluent-API her.
- Damit wir die Methoden aneinanderhängen können, muss jeder Methodenaufruf ein Result-Objekt zurückgeben. Also ergänzen wir die void-Methoden um ein entsprechendes return.
- Dadurch können wir nun die Methodenaufrufe aneinanderreihen, aber haben auch noch einen weiteren Vorteil geschaffen. Wir müssen nicht mehr wissen, welchen Zustand das Result-Objekt hat. Es entscheidet selbst, ob Operationen ausgeführt werden sollen oder nicht. Also haben wir eine Kapselung des Fehlerzustands erreicht.
- 12:00 Die onSuccess-Methode übernimmt das „Auspacken“ des Werts im Result-Objekt…
- ….und reicht es an einen Konsumenten weiter.
- Danach gibt sie das aktuelle – erfolgreiche – Result-Objekt zurück an den Aufrufer.
- Eine weitere hilfreiche Methode ist ensure(). -Methode prüft, ob der enthaltene Wert eine bestimmte Anforderung erfüllt, und gibt das Ergebnis zurück.
- Sie prüft, ob der enthaltene Wert eine bestimmte Anforderung erfüllt…
- …und gibt im Erfolgsfall das aktuelle Result-Objekt zurück…
- …bzw. andernfalls ein leeres fehlerhaftes Result.
- Und als letztes Beispiel wendet die map()-Methode...
- …die übergebene Funktion auf den Wert an…
- …die ihn ggfs. in einen anderen Typen umwandelt…
- …und verpackt das Resultat in ein neues Result-Objekt…
- …bzw. ein leeres fehlerhaftes Ergebnis.
- Wichtig ist noch, dass alle gezeigten Methoden gar nichts machen…
- wenn bereits ein fehlerhaftes Result-Objekt vorliegt.
- Die Methoden können nun wie in diesem Beispiel verkettet werden.
- Sobald eine der Methoden auf einen Fehler stößt, wird der Zustand des Results entsprechend verändert und kann von nun an nicht mehr verlassen werden. Und da dieser Ablauf so aussieht wie zwei parallel verlaufende Bahnschienen, hat der „Erfinder“ das Vorgehen Railway Oriented Programming genannt.
- Die Idee von ROP stammt von Scott Wlaschin, der die Website fsharpforfunandprofit.com betreibt.
- Aber so richtig darauf aufmerksam geworden bin ich durch den Pluralsight-Kurs von Vladimir Khorikov, in dem er das Konzept auf C# überträgt. Ja, ich weiß: ich habe ein Sakrileg begangen und bei C# rumgeschaut.
- Daran angelehnt habe ich mein eigenes Framework für ROP mit Java entwickelt, das ich bereits in „echten“ Projekten verwende.
- Und einen Artikel für Heise Online habe ich auch schon darüber geschrieben.
- Kommen wir nun zu einigen Vorteilen, die die Arbeit mit dem Result-Objekt im Vergleich zu Exceptions bietet.
- Altbekannter Code enthält oftmals einen Großteil an Exception Handling.
- Das macht ihn komplex und schwer zu verstehen.
- Die Verwendung der FluentAPI macht den Code kürzer und lesbarer und er enthält nun weniger rein technische Fehlerbehandlungsroutinen.
- Es werden keine teuren Exceptions, sondern potentiell leichtgewichtige Fehlerklassen verwendet, die auch einfach zu serialisieren sind. Dafür gibt es nachher noch ein Beispiel.
- Außerdem sind z.B. in Streams keine Methoden erlaubt, die Exceptions werfen.
- Dem kann man mit Result-Objekten gut begegnen.
- ROP hat allerdings – wie so ziemlich jede Idee in der Programmierung – auch ein paar Nachteile.
- Ein frühzeitiger Ausstieg aus der Aufrufkette ist nicht möglich und muss mit if/else geregelt werden.
- Die Verwendung des Results ist „ansteckend“. Genau wie Checked Exceptions, die sich von Methode zu Methode fortpflanzen.
- Der Verzicht auf Exceptions entspricht nicht dem üblichen Vorgehen zur Fehlerbehandlung, das die meisten Entwickler kennen.
- Aber dieses Umdenken hat an anderer Stelle schon stattgefunden bzw. nimmt rasant Fahrt auf. Viele Konzepte aus der funktionalen Programmierung verwenden Java-Entwickler seit Java 8 inzwischen täglich. Beispiele sind Optional und die allseits beliebten Streams.
- 19:00 Diese beiden Beispiele passen sehr gut zum Ansatz von ROP, da sie alle eins gemeinsam haben: es handelt sich um Monaden.
- Monaden kapseln ein abstraktes Konzept und erleichtern dem Entwickler den Umgang mit diesem.
- Optional: Repräsentiert das Nicht-/Vorhandensein eines Wertes und vermeidet ausufernde null-Checks.
- Stream: Repräsentiert potentiell mehrere Werte und vermeidet Iterationen.
- Promise: Repräsentiert das Ergebnis einer asynchronen Operation und vermeidet Thread-Programmierung.
- Result: Repräsentiert das potentiell fehlerhafte Ergebnis einer Operation und vermeidet Exception-Handling.
- Monaden sind abstrakte Datenstrukturen, die 3 grundlegende Funktionen anbieten müssen.
- 1) Ein Typkonstruktor, der die Monade mit einem Datentypen parametrisiert.
- Beispiele sind Optional<T> bzw. Result<TSuccess, TFailure>.
- 2) Eine Funktion, die aus einem normalen Datentypen eine Monade dieses Datentyps macht, ihn also quasi in der Monade einpackt. Diese Funktion heißt in funktionalen Programmiersprachen z.B. „return“ oder „unit“.
- Beispiele: Optional.of(5) macht aus dem Integer 5 ein Optional<Integer> Result.success(„Wert“) macht aus dem String „Wert“ ein Result<String>
- Optional.of() „verpackt“ den Basisdatentypen also in der Monade.
- 3) Eine Funktion, die eine andere Funktion als Parameter bekommt, die aus dem inneren Datentyp der Monade eine neue Monade eines beliebigen Datentyps erzeugt, und diese neue Monade zurückgibt. Der in der ursprünglichen Monade enthaltene Datentyp wir ausgepackt, die übergebene Funktion wird auf seinen Wert angewendet und das Ergebnis dieser Operation - das wiederum eine Monade ist, aber ggfs. mit einem anderen Datentypen - wird zurückgegeben. In funktionalen Sprachen heißt diese Funktion z.B. „bind()“ oder „flatMap()“.
- 22:00 Schauen wir uns ein Beispiel für flatMap() auf Stream an.
- Die erste Methode der Kette erzeugt einen Stream…
- …der allerdings Arrays als Elemente enthält, also eigentlich nicht nur jeweils einen Wert, sondern gleich mehrere.
- Auf die Elemente dieses Streams wird nun Stream.of() angewendet…
- …eine Methode, die aus einer Liste von Werten einen Stream dieser Werte erzeugt.
- Somit werden die einzelnen Arrays jeweils in einen neuen Stream umgewandelt.
- Und als Ergebnis erhalten wir einen Stream<Stream<Integer>>. Aber eigentlich hätten wir gerne einen „flachen“ Stream<Integer>.
- Und das übernimmt nun flatMap(). Die Methode „extrahiert“ die Teilstreams und hängt sie zu einem langen Stream einzelner Werte hintereinander.
- Die drei Funktionen müssen noch drei Gesetze einhalten.
- Dies sind die drei Gesetze in Haskell-Schreibweise. Wir wollen sie an dieser Stelle aufgrund fehlender Zeit nicht vertiefen. Letztlich geht es darum, wie Monaden und ihre Funktionen miteinander verkettet werden können.
- Eigentlich zählt Optional in Java damit nicht zu den Monaden, da eines der Gesetze verletzt wird. Aber das ist für den Praxiseinsatz nicht allzu relevant. „Bereits linke Identität ist nicht gewährleistet, weil es kein "unit" wie für Maybe gibt, das einfach nur den Wert wrappt. Optional hat zwar Optional.of, aber das schmeißt eine Exception, wenn man "null" übergibt und scheidet somit aus. Dann gibt es noch Optional.ofNullable, aber wenn man das mit null füttert, so bekommt man kein Optional(null), sondern ein Optional.Empty. Man hat also keine Möglichkeit, jeden beliegen Wert zu wrappen, daraus folgt, dass Optional.of(A).flatMap(f) == f(A) nicht immer erfüllt ist.“ Quelle: https://www.heise.de/forum/heise-Developer/Kommentare/Railway-Oriented-Programming-in-Java/Re-Java-versagt-Optional-ist-keine-Monade/posting-29819640/show/
- 24:00 Schauen wir uns nun ein paar Beispiele für den Praxiseinsatz der Result-Monade an.
- ROP lässt sich gut mit den Konzepten von DDD verbinden.
- Factory-Methoden für Value Objects bieten sich z.B. für den Rückgabetyp Result an, da sie meistens eine Form der Validierung enthalten, die erwartungsgemäß auch fehlschlagen kann.
- Das Result-Objekt könnte als Ersatz für die (teuren) Exceptions eingeführt werden, wenn der Fehlerfall ganz „normal“ ist, wie z.B. bei Validierungen. Eine „echte“ Ausnahme (z.B. Speicher voll), kann (und sollte) weiterhin eine Exception sein, die das Programm beendet.
- Hier ist ein Beispiel einer Fehler-Klasse aus einem echten Projekt, die als TFailure genutzt wird. Sie ermöglicht z.B. eine einfache Übersetzung aller möglichen Fehler an einer zentralen Stelle.
- Außerdem ist sie auch einfach zu serialisieren und z.B. per REST zu übertragen.
- Das mag aussehen wie ein Rückschritt zu prozeduralem Code mit Return Codes, aber in der Praxis ist das Vorgehen sehr gut einsetzbar und hat mir viel Zeit gespart. Außerdem wollen wir ja funktional entwickeln und LISP stammt auch aus den 1950er Jahren ;-)
- Testen kann man gegen das Result-Objekt auch sehr schön. Mit ein paar eigenen Hamcrest-Matchern lesen sich die JUnit-Tests sehr schön.
- So sieht der Testcode aus, der gegen Result-Objekte läuft.
- Monaden sind nicht nur etwas für Theoretiker. Die gezeigten Beispiele demonstrieren die Nützlichkeit für die tägliche Arbeit in der Praxis.
- Auch wenn einige Monaden in Java ggfs. nicht 100% konform zu den Regeln sind, kann man sie in der Praxis gut einsetzen.
- Dann kannst auch du bald sagen…
- Danke für die Aufmerksamkeit!
- Hier noch einmal meine Kontaktdaten.