Eu começaria com as diretrizes de design para exceções, que são curtas e inclui DO, DO NOT e EVOID. Também fornece os motivos.
No seu caso de exemplo, a seção revelvent seria Wrapping Exceptions
E esperaria que fosse escrito dessa maneira. Observe que ele captura uma exceção específica e tenta adicionar informações para que uma mensagem mais significativa seja propagada. Observe também que a exceção interna ainda é mantida para fins de registro
//In DataLayer
try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
throw new TransactionFileMissingException(
"Cannot Access System Information",ex);
}
ATUALIZAÇÃO
Kanini pergunta se é correto ter esse bloco de exceção na camada de dados ou se a verificação do arquivo está disponível para a camada de negócios.
Bem, primeiro eu gostaria de salientar que a lógica para Wrapping Exceptions é esta
Considere agrupar exceções específicas lançadas de uma camada inferior em uma exceção mais apropriada, se a exceção da camada inferior não fizer sentido no contexto da operação da camada superior.
Portanto, se você acha que uma camada superior deve saber sobre o arquivo, sua camada de dados deve ficar assim
//In DataLayer
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
Não tente não pegar.
Pessoalmente, sinto que, a menos que sua camada de dados possa fazer algo útil, como usar um systems.xml padrão que é um recurso de montagem, não fazer nada ou ocultar a exceção é uma boa aposta, já que o log mostrará qual método e qual arquivo foi o problema. ( throw exnesse caso, ou o preferido throwtambém, mas não agrega valor). Isso significa que, uma vez identificado, você poderá resolver o problema rapidamente.
Como exemplo, este exemplo em particular também tem o seguinte problema em que XDocument.Load pode lançar quatro exceções
- ArgumentNullException
- Exceção de segurança
- FileNotFoundException
- UriFormatException
Não podemos garantir com segurança que o código a seguir não será lançado e FileNotFoundException, simplesmente porque ele pode estar lá quando verificamos a existência e desaparecemos quando carregamos. Ter isso disponível para a camada de negócios não ajudaria.
if (File.Exists("systems.xml"))
XDocument.Load("systems.xml");
SecurityException é ainda pior, porque, entre outros motivos para isso ser lançado, se outro processo pegar um bloqueio de arquivo exclusivo, você não receberá o erro até tentar abri-lo para leitura, porque não existe o método File.CanIOpenThis (). E se esse método existir, você ainda terá o mesmo problema que o File.Exists