Nehmen wir ein Objekt an, das mit einem Builder-Muster erstellt wurde.

Dieses Buildermuster würde a enthaltenbuild Methode, die sich auf die Feldvalidierung und dann auf die Konvertierung in den Zieltyp konzentriert.

Diese Validierung könnte implementiert werden mit:

Either[FailureObject, TargetObject] ArtTry[TargetObject] (neues Feature von Scala 2.10)Validation[FailureObject, TargetObject] oderValidationNEL[FailureObject, TargetObject] aus der scalaz Bibliothek

Ich habe gelesen, dass einer der Hauptvorteile vonValidation ÜberEither Typ ist dasValidation kann Fehler "out of the box" ansammeln.

Aber was ist mit den "neuen"Try Weg? Ich bemerkte, dassTry hat auch "monadische" Methoden von der Stange, wiemap, flatMap etc ... was bei beiden typen wirklich gefehlt hat ohne hilfe vonProjection.

Daher würde ich mir vorstellen, dass jede Feldvalidierungsmethode a zurückgibtTry[FieldType] und genauer gesagt, im Falle eines Fehlers, aTry[SpecificFieldExceptionType]; Dieses verschachtelte enthält aString Nachrichtenfeld und ein rootCause-Feld, das im gesamtenbuild Methode.

Mit Scala 2.10 könnte oder sollteTry Ersetzen Sie die Scalaz-Validierungsbibliothek durch eine einfache Validierung, wie es das Builder-Muster beinhaltet.

**BEARBEITEN****

Durch LesenTry Quellcode, es klingt soTry kann nicht mehrere Ausnahmen akkumulieren und ist daher ausfallsicher ausgerichtet. SogarTry.flatMapGibt den potentiellen vorherigen Fehler zurück und hat daher nicht den Begriff der Akkumulation:

def flatMap[U](f: T => Try[U]): Try[U] = this.asInstanceOf[Try[U]]

Im Gegenteil vonValidationNEL die Akkumulationsfunktion handhabt.

Irgendeine Bestätigung?