Ola Guilherme, tenho explorado um pouco mais sobre Exceptions na MSDN. Lendo sobre o tema fiquei em duvida de quando realmente usar Exception, lançar uma exception.
Nao seria melhor criar metodos que garantam a correta digitacao do usuario ao inves de tratar como excecao quando ele nao coloca um parametro correto? o que me preocupou foi o texto abaixo sobre Performance.
Considerações sobre desempenho (https://docs.microsoft.com/pt-br/dotnet/api/system.exception?view=netframework-4.7.2)
Lançando ou tratando uma exceção consome uma quantidade significativa de recursos do sistema e o tempo de execução. Gera exceções somente para lidar com condições extraordinários realmente, não para manipular eventos previsíveis ou controle de fluxo. Por exemplo, em alguns casos, como quando você estiver desenvolvendo uma biblioteca de classes, é razoável lançar uma exceção se um argumento de método é inválido porque você espera que seu método ser chamado com parâmetros válidos. Um argumento de método inválido, se não for o resultado de um erro de uso, significa que alguma coisa extraordinária ocorreu. Por outro lado, lançará uma exceção se a entrada do usuário é inválida, porque você pode esperar que os usuários insiram ocasionalmente dados inválidos. Em vez disso, fornecem um mecanismo de repetição para que os usuários podem inserir uma entrada válida. Nem você deve usar exceções para lidar com erros de uso. Em vez disso, use asserções para identificar e corrigir erros de uso.
Além disso, não lance uma exceção quando um código de retorno é suficiente; Não converta um código de retorno em uma exceção; e fazer catch não rotineiramente uma exceção, ignorá-lo e, em seguida, continuar o processamento.
Voce acha interessante entender melhor e considerar usar o Debug.Assert e Trace.Assert e deixar excecoes para casos realmente excepcionais como nullReference, memory etc. O que recomenda? Ou devo continuar usando exceptions para validacoes de argumentos, operacoes como divisor por zero etc?
