Vamos supor que um objeto seja construído usando um padrão de construtor.

Esse padrão de construtor conteria umbuild método com foco na validação de campos e, em seguida, na conversão para o tipo de destino.

Essa validação pode ser implementada usando:

Either[FailureObject, TargetObject] tipoTry[TargetObject] (novo recurso do Scala 2.10)Validation[FailureObject, TargetObject] ouValidationNEL[FailureObject, TargetObject] de biblioteca de scalaz

Eu li que uma das principais vantagens deValidation sobreEither tipo é aqueleValidation pode acumular falhas "fora da caixa".

Mas e o "novo"Try caminho? eu percebi issoTry tem métodos "monádicos" fora da caixa também, comomap, flatMap etc ... o que realmente estava faltando com qualquer tipo sem ajuda deProjection.

Assim, eu imagino que cada método de validação de campoTry[FieldType] e mais precisamente, em caso de falha, umTry[SpecificFieldExceptionType]; este aninhado contendo umString campo de mensagem e um campo rootCause que pode ser acumulado em todo obuild método.

Usando o Scala 2.10, poderia ou deveriaTry prática substituir biblioteca de validação scalaz para validação simples como padrão de construtor envolve?

**EDITAR****

Pela leituraTry código-fonte, parece queTry não pode acumular várias exceções e, portanto, é orientado para fail-fast. AtéTry.flatMapretorna a falha anterior potente e, portanto, não tem a noção de acumulação:

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

Ao contrário deValidationNEL que lida com o recurso de acumulação.

Alguma confirmação?