Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Fehler als Werte - Ausnahmebehandlung in der funktionalen Programmierung

Fehler als Werte - Ausnahmebehandlung in der funktionalen Programmierung

In imperativen Programmiersprachen erfolgt Fehlerbehandling in der Regel über das Werfen von Exceptions. Funktionale Sprachen hingegen betrachten Fehler meist als Werte, die ebenso wie andere Werte behandelt werden können.

Der Vortrag vergleicht den funktionalen mit dem imperativen Ansatz, und zeigt Vor- und Nachteile auf.

Gehalten wurde der Vortrag im Rahmen eines "Lightning-Talk" Abends der Java User Group Mannheim.

In imperativen Programmiersprachen erfolgt Fehlerbehandling in der Regel über das Werfen von Exceptions. Funktionale Sprachen hingegen betrachten Fehler meist als Werte, die ebenso wie andere Werte behandelt werden können.

Der Vortrag vergleicht den funktionalen mit dem imperativen Ansatz, und zeigt Vor- und Nachteile auf.

Gehalten wurde der Vortrag im Rahmen eines "Lightning-Talk" Abends der Java User Group Mannheim.

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Fehler als Werte - Ausnahmebehandlung in der funktionalen Programmierung

  1. 1. Fehler als Werte - Ausnahmebehandlung in der funktionalen Programmierung majug² – 01.06.2017 Mario Philipps
  2. 2. Klassisches Fehlerhandling • Imperative Steinzeit: Call meldet Fehler über Fehlercode • Übersehener Fehlercode führt zu undefiniertem Zustand • Heute: „Unsichtbare“ Unterbrechung des Ablaufs durch Exceptions • Undefinierter Zustand wird vermieden • In den meisten Fällen absolut ausreichend! • Aber: Möglichkeit des Abbruchs kann übersehen werden
  3. 3. Checked Exceptions • Versuch einer Lösung: Checked Exceptions • Zuviel Overhead im Standardfall • „Überschreiben“ bei partiellen Funktionen erzeugt Boilerplate Code final Value value; try { value = getValueWithPossibleException(inputKnownToBeSafe); } catch (final Exception e) { // can't happen, because input is safe throw new RuntimeException(e); }
  4. 4. Funktionales Fehlerhandling • Exceptions nicht nur technisches Vehikel zum Prozessabbruch • Auch Repräsentationen eines Fehlerzustandes Domänenkonzepte Werte • Können wie andere Werte behandelt werden Als Ergebnis eines Funktionsaufrufs Als Wert von Variablen oder Feldern
  5. 5. Wert Fehler Try Try als Monade Wert .flatMap( ) Fehler • Was ist eine Monade!? • … alles was eine .flatMap() Methode hat Try .flatMap( ) Try<U> Try<T>.flatMap(Function<T, Try<U>> mapper)
  6. 6. Try vs. Checked Exceptions • Mittelweg zwischen Checked und Unchecked Exceptions? • Umgang mit Fehlersituationen durch Compiler erzwungen • „Überschreiben“ mit sehr viel weniger Aufwand möglich final Value value; try { value = getValueWithPossibleException(inputKnownToBeSafe); } catch (final Exception e) { // can't happen, because input is safe throw new RuntimeException(e); } final Value value = getTriedValue(inputKnownToBeSafe).get(); // input is safe vs.
  7. 7. Try vs. Checked Exceptions • Keine Möglichkeit, mehrere Exceptiontypen syntaktisch zu unterscheiden • Kein syntaktischer Zucker für Monaden in Java • Boilerplate Code verschmutzt Happy Case Code public Value someProcessedValue() throws Exception { final String value = someValue(); return processed(value); } public Try<String> someProcessedValue() { final Try<String> value = someValue(); return value.flatMap(successfulValue -> processed(successfulValue)); } vs.
  8. 8. • Werfen von Unchecked Exceptions meist ausreichend • Fehler als Rückgabewerte (Try) sinnvoll, wenn • Werte nur zum Teil ermittelt werden können • Informationen darüber im Caller benötigt werden • Weiterverarbeitung von Trys erfolgt über Monadenoperationen • Monadenoperationen erzeugen Boilerplate Code tl;dl

×