Załóżmy, że obiekt został skonstruowany przy użyciu wzoru budowniczego.

Ten wzór konstruktora zawierałbybuild metoda skupiająca się na walidacji pól, a następnie na konwersji do typu docelowego.

Ta walidacja może zostać wdrożona przy użyciu:

Either[FailureObject, TargetObject] rodzajTry[TargetObject] (nowa funkcja ze Scala 2.10)Validation[FailureObject, TargetObject] lubValidationNEL[FailureObject, TargetObject] z biblioteki skalazów

Przeczytałem jedną z głównych zaletValidation koniecEither typ jest takiValidation może gromadzić awarie „po wyjęciu z pudełka”.

Ale co z „nowym”Try sposób? zauważyłem toTry ma też metody „monadyczne”map, flatMap itp. ... czego tak naprawdę brakowało w obu typach bez pomocyProjection.

Dlatego wyobrażam sobie, że każda metoda sprawdzania poprawności pola zwraca aTry[FieldType] a dokładniej w przypadku jakiejkolwiek awarii:Try[SpecificFieldExceptionType]; ten zagnieżdżony zawiera aString pole wiadomości i pole rootCause, które mogą być gromadzone w całymbuild metoda.

Używając Scala 2.10, mógł lub powinienTry praktyka zastąpić bibliotekę walidacji skalazów dla prostej walidacji, jak to się dzieje w przypadku wzorca budującego?

**EDYTOWAĆ****

CzytającTry kod źródłowy, to brzmi takTry nie może gromadzić kilku wyjątków i dlatego jest zorientowany na awarię. ParzystyTry.flatMapzwraca potencjalną poprzednią awarię i nie ma pojęcia akumulacji:

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

Wręcz przeciwnieValidationNEL który obsługuje funkcję akumulacji.

Jakieś potwierdzenie?