Asumamos un objeto construido usando un patrón de construcción.

Este patrón de construcción contendría unbuild Método que se centra en la validación de campos y luego en la conversión al tipo de destino.

Esta validación podría implementarse utilizando:

Either[FailureObject, TargetObject] tipoTry[TargetObject] (nueva característica de Scala 2.10)Validation[FailureObject, TargetObject] oValidationNEL[FailureObject, TargetObject] de la biblioteca de Scalaz

Leí que una de las principales ventajas deValidation terminadoEither tipo es eseValidation Puede acumular fallos "fuera de la caja".

Pero ¿qué pasa con el "nuevo"Try ¿camino? Me di cuenta queTry tiene métodos "monádicos" fuera de la caja también, comomap, flatMap etc ... lo que realmente faltaba con cualquiera de los dos tipos sin ayuda deProjection.

Por lo tanto, me imagino que cada método de validación de campo devolver unTry[FieldType] Y más precisamente, en caso de cualquier fallo, unTry[SpecificFieldExceptionType]; este anidado que contiene unaString campo de mensaje y un campo de causa raíz que podría acumularse a lo largo delbuild método.

Usando Scala 2.10, podría o deberíaTry ¿la práctica reemplaza la biblioteca de validación de scalaz para una validación simple como el patrón de construcción involucra?

**EDITAR****

LeyendoTry código fuente, suena queTry no puede acumular varias excepciones y, por lo tanto, está orientado a fallas. InclusoTry.flatMapdevuelve el fallo anterior potencial y, por lo tanto, no tiene la noción de acumulación:

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

Al contrario deValidationNEL que maneja la característica de acumulación.

¿Alguna confirmación?