Comenzaría con las Pautas de diseño para excepciones, que son cortas e incluyen DO, DO NOT y EVOID. También da las razones por qué.
En su caso de ejemplo, la sección revelvent sería Envolviendo excepciones
Y esperaría que se escribiera de esta manera. Tenga en cuenta que detecta una excepción específica e intenta agregar información para que se propague un mensaje más significativo. También tenga en cuenta que la excepción interna todavía se mantiene para fines de registro
//In DataLayer
try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
throw new TransactionFileMissingException(
"Cannot Access System Information",ex);
}
ACTUALIZACIÓN
Kanini pregunta si es correcto tener este bloque de excepción en la capa de datos o si la comprobación del archivo está disponible para la capa empresarial.
Bueno, primero me gustaría señalar que la justificación de las excepciones de envoltura es esta
Considere envolver excepciones específicas lanzadas desde una capa inferior en una excepción más apropiada, si la excepción de la capa inferior no tiene sentido en el contexto de la operación de la capa superior.
Entonces, si cree que una capa superior debe saber sobre el archivo, su capa de datos debería verse así
//In DataLayer
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
No intente sin captura.
Personalmente, creo que a menos que su capa de datos pueda hacer algo útil, como usar un sistema predeterminado.sml que es un recurso de ensamblaje, no hacer nada o envolver la excepción es una buena apuesta, ya que su registro le dirá qué método y qué archivo fue el problema. ( throw exen este caso o el preferido throwtambién, pero no agrega valor). Esto significa que una vez identificado, podrá solucionar el problema rápidamente.
Como ayuda, este ejemplo en particular también tiene el siguiente problema, ya que XDocument.Load puede arrojar cuatro excepciones.
- ArgumentNullException
- Excepcion de seguridad
- FileNotFoundException
- UriFormatException
No podemos garantizar con seguridad que el siguiente código no se lanzará y FileNotFoundException, simplemente porque podría estar allí cuando verificamos la existencia y desaparecer cuando cargamos. Tener eso disponible para la capa empresarial no ayudaría.
if (File.Exists("systems.xml"))
XDocument.Load("systems.xml");
SecurityException es aún peor porque, entre otras razones, si esto se produce si otro proceso agarra tiene un bloqueo de archivo exclusivo, no obtendrá el error hasta que intente abrirlo para leerlo porque no hay un método File.CanIOpenThis (). Y si existiera tal método, todavía tiene el mismo problema que con File.Exists