Best Practice: Wann verwendet ihr Exceptions in Funktionen?

[Meflin]

Zitat von JasonDX:

was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null?

Das hast du falsch verstanden. Das ist so garnicht möglich. Du hast als Rückgabe z.B. ein Try[Int]. Dann ist das entweder ein Failure oder ein Success Objekt. Die konkrete Weiterverwendung ist dann sehr stark abhängig vom spezifischen Anwendungsfall. Aber du kannst mit dem Objekt erstmal weiterarbeiten, ohne zu wissen, was von beiden es ist. Also z.B.

Code:

maybeInt.map(x => x * 2)

Die Überprüfung, ob die ganze Geschichte erfolgreich war, musst du genau ein mal machen, nämlich zum Schluss, genau dann, wenn du das Endergebnis brauchst. Da man mehrere Trys auf diese Weise problemlos verketten kann, sparst du dir da SEHR VIEL Fehlerbehandlungscode.

Zitat:

(Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Ist richtig, aber dieser Fall hat nicht sonderlich viel mit funktionaler Programmierung zu tun (außer der Verwendung von Lambdas, die immer nützlich sind).

Zitat:

Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.

Ist mir schon klar, dass das nichts mit Interrupts zu tun hat. Was ich meinte war das Konzept "ich breche einfach mal mitten drin komplett ab, egal was ich gerade mache, und springe zu einer völlig anderen Codestelle", was beide durchaus gemeinsam haben.

Zitat von Meflin:

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions

Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):

Code:

interface IComputation {
  function currentValue: Float;
  function multiplyBy(other: Float): IComputation;
  function divideBy(other: Float): IComputation;
}

class Computation extends IComputation {
  
  function divideBy(other: Float): IComputation {
    if (other = 0) return new NullComputation();
    return new Computation(this.currentValue / other);
  }
  ...

}

class NullComputation extends IComputation {
  function currentValue: Float { return Float.NaN }
  function divideBy(other: Float): IComputation { return this; }
  ...
}

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN