É uma boa prática lançar uma exceção nos methods Validate () ou melhor para retornar o valor bool?

É recomendado ou não lançar exceções de methods de validação como:

ValidateDates(); ValidateCargoDetails(); 

Além disso: há um padrão de design de validação robusto usado com frequência?

Eu sugeriria retornar um object ValidationResult contendo ValidationFailures. Você nunca deve usar exceções como parte de sua codificação lógica. Exceções são para exceções

Eu costumo usar visitor pattern para validar a input; acumulando todos os erros em uma lista ou algo para mostrar ao usuário. A lógica é como, verificar a lista de erros de validação, se encontrado, informar o usuário, caso contrário, é bom ir.

IMO, erros de validação não são algo excepcional, portanto, não deve ser tratado como um.

Eu diria que tudo depende do que / como você está fazendo a validação. Mas no final do dia um desenvolvedor pode sempre optar por ignorar um resultado retornado (esse é o problema com eles), eles não podem ignorar uma exceção sem escrever código explícito para fazer isso.

Alot depende de quão excepcionais são as falhas de validação, quão crítico é estar correto.

Se suas falhas de validação forem raras e severas ou fatais quando ocorrerem, usarei Exceções ou até AssertionErrors. A maioria dos analisadores usa exceções e estas indicam que não é possível continuar o processamento.

Se sua falha de validação for esperada como em operações normais e não indicar que você não pode continuar processando, sugiro usar um padrão de visitante ou retornar uma lista de problemas (que podem estar vazios)

A exceção de lançamento não deve ser usada para controlar o stream do aplicativo . Como o nome indica, isso acontece em casos excepcionais , enquanto a validação pode falhar. Eles também são caros e afetam o desempenho.

Eu iria com o retorno de um booleano mais uma string para a razão .

Os usuários que inserem dados inválidos são a própria definição de exceção. Ao gravar requisitos de negócios para uma solução, você sempre grava os caminhos sem erro como o stream principal e os caminhos de erro como caminhos excepcionais. Usar exceções para validação é perfeitamente aceitável. A validação com exceções também permite priorizar a ordem em como elas são manipuladas e lidar com o erro de maneira diferente, dependendo do nível em que você está na pilha da arquitetura (uma string descrevendo o erro é de pouca utilidade na camada de access a dados).