Railway Oriented Programming – Mit Exceptions im Gleis bleiben

Und dann war es endlich so weit. Wir durften unser Java 8 auspacken. Mit den Monaden Optional und Stream wurden uns damit mächtige Werkzeuge geschenkt. Plötzlich musste sich das Programmiermodell nicht mehr sklavisch an der von Neuman-Architektur orientieren. Stattdessen konnte nun Code verfasst werden, der Algorithmen in deklarativer Form realisierte. Herausgekommen ist dabei besser lesbarer und seiteneffektfreier Code. Daher werden Optional und Stream von den meisten Entwicklern heute wohl täglich benutzt. Warum hat man für die Fehlerbehandlung nicht den gleichen Weg eingeschlagen? Noch immer ist unser Code mit dem sehr technischen Exception-Handling verwoben. Kritische Stimmen bezeichnen dies als das letzte verbliebene Goto in der Sprache. Dabei haben wir uns doch auf die Fahnen geschrieben, mehr fachlichen Code zu schreiben. Geht das besser? In der funktionalen Programmierung gibt es hierfür Railway Oriented Programming. Vereinfacht gesagt wird hierbei der Kontrollfluss nicht verlassen, sondern der Fehlerzustand auf einem „Nebengleis“ durch den Programmablauf geleitet. In diesem Talk wollen wir der Frage nachgehen, wie gut sich Railway Orientend Programming in Java anwenden lässt. Wir werden dabei auf die unterschiedlichen Möglichkeiten der Realisierbarkeit eingehen. Durch die Gegenüberstellung von Code-Beispielen sollte am Ende jeder in der Lage sein zu beurteilen, ob damit sauberer und besser wartbarer Code geschrieben werden kann.