Je commencerais par Design Guidelines for Exceptions, son court et comprend DO, DO NOT et EVOID. Il explique également pourquoi.
Dans votre exemple, la section revelvent serait Wrapping Exceptions
Et s'attendrait à ce qu'il soit écrit de cette façon. Notez qu'il intercepte une exception spécifique et tente d'ajouter des informations afin qu'un message plus significatif soit propagé. Notez également que l'exception interne est toujours conservée à des fins de journalisation
//In DataLayer
try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
throw new TransactionFileMissingException(
"Cannot Access System Information",ex);
}
UPDATE
Kanini demande s'il est même juste d'avoir ce bloc d'exception dans la couche de données ou si la vérification du fichier est disponible pour la couche métier.
Eh bien tout d'abord, je voudrais souligner que la justification des exceptions d'emballage est la suivante
Envisagez d'envelopper des exceptions spécifiques levées à partir d'une couche inférieure dans une exception plus appropriée, si l'exception de couche inférieure n'a pas de sens dans le contexte de l'opération de couche supérieure.
Donc, si vous pensez que la couche supérieure devrait connaître le fichier, votre couche de données devrait ressembler à ceci
//In DataLayer
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
No Try No Catch.
Personnellement, je pense qu'à moins que votre couche de données puisse faire quelque chose d'utile comme utiliser un fichier systems.xml par défaut qui est une ressource d'assemblage, ne rien faire ou encapsuler l'exception est un bon pari puisque votre journalisation vous dira quelle méthode et quel fichier ont été le problème. ( throw ex
dans ce cas ou le préféré throw
aussi mais n'ajoute aucune valeur). Cela signifie qu'une fois identifié, vous pourrez résoudre le problème rapidement.
En tant qu'asside, cet exemple particulier a également le problème suivant en ce que XDocument.Load peut lancer quatre exceptions
- ArgumentNullException
- Exception de sécurité
- FileNotFoundException
- UriFormatException
Nous ne pouvons pas garantir en toute sécurité que le code suivant ne lèvera pas et FileNotFoundException, simplement parce qu'il pourrait être là lorsque nous vérifions l'existence et disparu lorsque nous chargeons. Avoir cela à la disposition de la couche métier n'aiderait pas.
if (File.Exists("systems.xml"))
XDocument.Load("systems.xml");
SecurityException est encore pire car, entre autres raisons, si un autre processus s'empare d'un verrou de fichier exclusif, vous n'obtiendrez pas l'erreur jusqu'à ce que vous essayiez de l'ouvrir pour la lecture car il n'y a pas de méthode File.CanIOpenThis (). Et si une telle méthode existait, vous avez toujours le même problème qu'avec File.Exists