Sobre excepciones en .net

Excepciones

El framework de .net utiliza un mecanismo para informar de situaciones que impiden el flujo normal del código como un error, se trata de las excepciones.

 Las excepciones se pueden producir por muchas razones, en general situaciones inesperadas, por ejemplo querer acceder a un archivo que no existe, esto produce una horrible excepción, veamos un poco de código

using (StreamReader reader = new StreamReader(@"c:\archivoQueNoExiste.txt"))
{
 reader.ReadLine();
 reader.Close();
}

 Si lo ejecutamos recibimos una fea fea excepción del tipo FileNotFoundException, ok esto es lo que queríamos, ahora bien, qué hacemos ahora?

Alternativa ante las excepciones

Inicialmente podemos hacer dos cosas cuando nos encontramos con una porción de código que puede lanzar una excepción

-Atraparla en un bloque catch

-No hacer nada

Comencemos por el primer caso

try 
{ 
 using (StreamReader reader = new StreamReader(@"c:\archivoQueNoExiste.txt")) 
 { 
  reader.ReadLine();
  reader.Close();
 } 
}catch 
{ 
 throw;
} 

Qué pasa acá, bien, lo mismo que no hacer nada, porque en el bloque volvemos a lanzar la excepción por lo tanto es lo mismo que no hacer nada

try 
{ 
 using (StreamReader reader = new StreamReader(@"c:\archivoQueNoExiste.txt")) 
 { 
 reader.ReadLine();
 reader.Close();
 } 
}catch(Exception ex) 
{ 
 throw ex;
} 

Este ejemplo es peor que el anterior porque no sólo no hacemos nada sino que además al colocar Exeception ex y luego hacer throw borramos toda la información que se recopiló hasta el momento del error (el stack trace) por lo tanto, no sólo no la manipulamos sino que además perdemos valiosa información.

Enseñanza:

-Si atrapamos una excepción y la relanzamos haciendo referencia al objeto Exception borramos el stack trace.

try 
{ 
 using (StreamReader reader = new StreamReader(@"c:\archivoQueNoExiste.txt")) 
 { 
  reader.ReadLine();
  reader.Close();
 } 
}catch(Exception ex) 
{ 
 GuardarInformacionDelError(ex);
} 

Esto es bastante más elegante, ocurre un error y guardamos la información para un análisis posterior, sin embargo esto nos lleva a una enseñanza mejor, por qué no hacer mejor esto:

string nombre = @"c:\archivoQueNoExiste.txt";
if (File.Exists(nombre))
{ 
 using (StreamReader reader = new StreamReader(nombre)) 
 { 
  reader.ReadLine();
  reader.Close();
 }
}

 Nada de nada, no ocurre la excepción porque estamos verificando de antemano la existencia del archivo, la enseñanza es que es mejor evitar las excepciones, porque son costosas a nivel recursos y son feas también.

 Manejando excepciones

En caso de querer manejar la excepción o que ocurra una excepción inesperada por ejemplo:

string nombre = @"c:\archivoQueNoExiste.txt";
if (File.Exists(nombre))
{
 using (StreamWriter writer = new StreamWriter(nombre))
 { 
  writer.Write("hola mundo");
  writer.Close();
 }
}

 y que el archivo sea de sólo lectura o algo así (obviamente también podemos verificarlo antes, es un ejemplo), entonces tenemos un bloque de código en el catch para manipular la excepción, pero qué hacemos? Primero que nada podemos guardar información de error, segundo lanzar otra excepción, una personalizada, indicando un problema con información más "amigable"

try 
{
 string nombre = @"c:\archivoQueNoExiste.txt";
 if (File.Exists(nombre)) 
 {
  using (StreamWriter writer = new StreamWriter(nombre))
  {
   writer.Write("hola mundo"); 
   writer.Close();
  }
 }
}catch (Exception ex) 
{
 GuardarInformacionDelError(ex);
 throw new ExcepcionPersonalizada("Ocurrión un error sentimos las molestias");
 }

 Un lujo asiático, vamos a hacer un resumen de lo que aprendimos

-Siempre es mejor verificar para evitar las excepciones que esperar que ocurran

-Si ocurren y vamos a atraparlas hay que manipularlas correctamente, de muy poco sirve relanzar la misma excepción

Tipificando excepciones

Las excepciones son objeto de una clase, todas heredan de la clase base Exception y las podemos diferenciar por el tipo, nada de códigos de error ni cosas raras

Esta tipificación nos permite poder hacer cosas simpáticas filtrando las excepciones, veámos el siguiente ejemplo:

try 
{ 
 string nombre = @"c:\archivoQueNoExiste.txt";
 if (File.Exists(nombre)) 
 {
  using (StreamWriter writer = new StreamWriter(nombre))
  {
   writer.Write("hola mundo"); 
   writer.Close();
  }
 }
}catch (UnauthorizedAccessException)
{
 throw new ExcepcionPersonalizada("No se puede acceder al archivo");
}catch (Exception ex) 
{ 
 GuardarInformacionDelError(ex);
 throw new ExcepcionPersonalizada("Ocurrió un error inesperado"); 
}

 En este caso en caso de ocurrir una excepcion del tipo UnauthorizedAccessException vamos a lanzar otra indicando que no se puede acceder al achivo, ahora cuando ocurra cualquier otra excepción se va a guardar la información y se va a lanzar una excepción personalizada indicando que pasó algo raro. Ahora, sabemos que UnautorizedAccessException hereda de SystemException qué pasa si hacemos esto?:

try 
{ 
 string nombre = @"c:\archivoQueNoExiste.txt";
 if (File.Exists(nombre)) 
 {
  using (StreamWriter writer = new StreamWriter(nombre))
  {
   writer.Write("hola mundo"); writer.Close();
  }
 }
}catch (UnauthorizedAccessException)
{
 throw new ExcepcionPersonalizada("No se puede acceder al archivo"); 
}catch (SystemException)
{
 throw new ExcepcionPersonalizada("Error de sistema");
}catch (Exception ex)
{
 GuardarInformacionDelError(ex);
 throw new ExcepcionPersonalizada("Ocurrió un error inesperado");
}

 Bien, se ejecuta el bloque que tiene UnauthorizedAccessException porque siempre se ejecuta primero el bloque con el tipo más especializado, es decir, como la excepción es del tipo UnauthorizedAccessException por más que esta herede de SystemException se ejecuta su bloque para que podamos hacer algo con ese tipo en particuar de excepción, otra cosa con todas las otras excepciones que hereden de systemException y por útlimo otra cosa con el resto.

Otra enseñanza

-Cuando tenemos varios bloque catch se ejecuta el que tiene el tipo que mejor encaja con el de la excepción que se produjo y sólo ese.

 Ahora bien, qué pasa si hacemos esto:

try 
{
 string nombre = @"c:\archivoQueNoExiste.txt";
 if (File.Exists(nombre))
 {
  using (StreamWriter writer = new StreamWriter(nombre))
  {
   writer.Write("hola mundo"); writer.Close();
  }
 }
}catch (ApplicationException)
{
 throw new ExcepcionPersonalizada("No se puede acceder al archivo");
}

 Nadie atrapa la excepción porque estamos sólo teniendo en cuenta las del tipo ApplicationException y deribadas y no es el caso de UnauthorizedAccessException, entonces la excepción "burbujea" al método que invocó al actual y seguirá haciendo esto hasta que algún bloque maniuple la excepción, si esto nunca ocurre la aplicación pincha, o más técnicamente, el CLR la finaliza con un carte muy feo que habla acerca de nuestro descuído.

Otra enseñanza

-Si no atrapamos una excepción esta burbujea a la capa superior y así sucesivamente hasta que alguien la manipula o el CLR interrumpe la aplicación

No utilizar excepciones como control de flujo para reglas de negocios

Un tema polémico, no es recomendable utilizar excepciones personalizadas para controlar el flujo de la aplicación por dos razones:

-Son costosas a nivel recursos

-Y se llaman excepciones porque deben ocurrir sólo en ocasiones excepcionales

Auque puede haber casos en los que se utilicen, por ejemplo, escribimor un servicio web para que consuma alquien a través de internet, poco seguro sería si la validación de los datos del usuario devolviese un valor booleano si la autenticación del mismo fuera errónea, creo que más de uno pensaría en que es sencillo saltarla, en este caso lo más recomendable es lanzar una excepción para que se interrumpa la comunicación directamente.

Crear excepciones personalizadas

Bueno, no hay mucho para decir, simplemente hay que seguir una regla, que nuestras excepciones hereden de ApplicationException porque Exception está reservada para excepciones del CLR, esto nos va a permitir un mejor filtrado, más aún si definimos nuestra propia excepción base y hacemos heredas todas nuestras excepciones de esta.

Hasta la próxima.