Sempre derivar da classe Exception
Ao criar classes de exceção personalizadas, sempre derive da classe Exception, não da classe ApplicationException. Um dos motivos para isso é que uma instância de ApplicationException é lançada somente pelo aplicativo e nunca pelo tempo de execução. Sempre que você lança uma instância de ApplicationException no seu código, você apenas aumenta a pilha de chamadas sem adicionar muito valor.
Lidar com exceções no mais alto nível
Observe que as exceções são borbulhadas para o nível mais alto na hierarquia de chamadas de método, e não é uma boa prática manipular exceções em todas as camadas do seu aplicativo. Você deve manipular uma exceção o mais alto possível na hierarquia de chamadas. Por exemplo, você pode consumir uma exceção na camada de apresentação e exibir mensagens apropriadas ao usuário para comunicar o erro exato que ocorreu.
Use exceções predefinidas e mensagens de erro claras
É uma boa prática usar exceções específicas como FileNotFoundException e IOException ao escrever manipuladores de exceção e, em seguida, um bloco catch geral no final com a classe Exception. Isso garantirá que você tenha uma compreensão clara do erro exato que ocorreu. Como afirma a documentação da Microsoft: “A classe ApplicationException não fornece informações sobre a causa das exceções. Na maioria dos cenários, instâncias dessa classe não devem ser lançadas. Em casos em que essa classe é instanciada, uma mensagem legível por humanos descrevendo o erro deve ser passada para o construtor.”
