Vorrei iniziare con le Linee guida per la progettazione delle eccezioni, che sono brevi e include DO, DO NOT e EVITARE. Fornisce anche i motivi per cui.
Nel tuo esempio, la sezione revelvent sarebbe Wrapping Exceptions
E si aspetterebbe che sia scritto in questo modo. Si noti che rileva un'eccezione specifica e tenta di aggiungere informazioni in modo da propagare un messaggio più significativo. Si noti inoltre che l'eccezione interna è ancora mantenuta ai fini della registrazione
//In DataLayer
try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
throw new TransactionFileMissingException(
"Cannot Access System Information",ex);
}
AGGIORNAMENTO
Kanini chiede che sia giusto avere questo blocco di eccezioni nel livello dati o se il controllo del file deve essere disponibile per il livello aziendale.
Bene, prima vorrei sottolineare che la logica di Wrapping Exceptions è questa
Prendi in considerazione la possibilità di racchiudere eccezioni specifiche generate da un livello inferiore in un'eccezione più appropriata, se l'eccezione del livello inferiore non ha senso nel contesto dell'operazione di livello superiore.
Quindi, se ritieni che avere un livello superiore debba conoscere il file, il tuo livello dati dovrebbe apparire così
//In DataLayer
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
No Try No Catch.
Personalmente ritengo che, a meno che il tuo livello dati non sia in grado di fare qualcosa di utile come utilizzare un files.xml predefinito che è una risorsa di assemblaggio, non fare nulla o racchiudere l'eccezione è una buona scommessa poiché la tua registrazione ti dirà quale metodo e quale file è stato il problema. ( throw exin questo caso o anche il preferito lo throwfa ma non aggiunge alcun valore). Ciò significa che, una volta identificato, sarai in grado di risolvere rapidamente il problema.
Inoltre questo particolare esempio presenta anche il seguente problema in XDocument.Load può generare quattro esecuzioni
- ArgumentNullException
- SecurityException
- FileNotFoundException
- UriFormatException
Non possiamo garantire con sicurezza che il seguente codice non genererà FileNotFoundException, semplicemente perché potrebbe essere lì quando eseguiamo il controllo dell'esistenza e spariamo quando lo cariciamo. Avere questo a disposizione per il livello aziendale non sarebbe d'aiuto.
if (File.Exists("systems.xml"))
XDocument.Load("systems.xml");
SecurityException è anche peggio perché tra le altre ragioni per cui viene lanciata se un altro processo prende un blocco di file esclusivo non otterrai l'errore fino a quando non provi ad aprirlo per la lettura perché non esiste un metodo File.CanIOpenThis (). E se esistesse un metodo del genere, hai ancora lo stesso problema di File.Exists