Durante este tema se van a tratar de 2 tipos de errores: los de ejecución y los lógicos. Ignoramos los errores de compilación.

Transcripción

1 TEMA 7: ERRORES 1. CONCEPTOS PREVIOS Durante este tema se van a tratar de 2 tipos de errores: los de ejecución y los lógicos. Ignoramos los errores de compilación. De ejecución: Son las excepciones que aparecen en tiempo de ejecución como por ejemplo la incapacidad de abrir la base de datos. De compilación: Son errores que Visual Studio nos señala al compilar la página. Suelen ser faltas semánticas o sintácticas en el código. Lógicos: Cuando el resultado aparecido no es el esperado. Por ejemplo cuando cargamos un usuario inexistente. No dará error, pero no aparece el registro esperado. 2. ERRORES EN LAS CLASES INDEPENDIENTES Siguiendo la guía de programación del de la UA tenemos la obligación de incorporar una propiedad pública llamada Debug. Esta propiedad de solo lectura incorporará los mensajes de error o de atención de los métodos. Será solo útil para el programador. ERRORES LÓGICOS Así, si por ejemplo, si se intenta cargar un usuario vacio Debug recogerá el mensaje no se ha encontrado al usuario. Esto se envía como un aviso (un warning) y será responsabilidad de la página apsx que haga uso de este método el que gestione el aviso. La clase no lanzará excepción. Ejemplo: Supongamos estas 2 clases: using System; public class ClaseAnimal private string _debug; public int Identificador get; set; public string Nombre get; set; public string Debug get return _debug; public ClaseAnimal Carga(int Animal) ClaseAnimal MiAnimal = new ClaseAnimal(); MiAnimal = ClaseAnimales.Todo().Find( delegate(claseanimal ca) return (ca.identificador== Animal); ); //Si encuentra animal devuelvelo if (MiAnimal!= null) return MiAnimal; else Tema 4 / Página 1

2 //Si no Debug toma valor y devuelvo un animal sin datos _debug += "No se ha encontrado el animal"; return new ClaseAnimal Identificador=0, Nombre="" ; using System.Collections.Generic; public static class ClaseAnimales public static List<ClaseAnimal> Todo() ClaseAnimal Animal = new ClaseAnimal(); List<ClaseAnimal> Animales = new List<ClaseAnimal> new ClaseAnimal Identificador=1, Nombre="Elefante", new ClaseAnimal Identificador=2, Nombre="Tigre" ; return (Animales); En este ejemplo un aspx como el que sigue: <form id="form1" runat="server"> <div> <asp:label ID="Label1" runat="server" Text="Label"></asp:Label> <asp:textbox ID="TextBox1" runat="server" ontextchanged="textbox1_textchanged"></asp:textbox> </div> </form> Con este cs asociado protected void TextBox1_TextChanged(object sender, EventArgs e) ClaseAnimal MiAnimal = new ClaseAnimal(); string nombre = MiAnimal.Carga( int.parse(textbox1.text)).nombre; //La variable debug me sirve para determinar si todo ha ido ok if (MiAnimal.Debug!= null) Label1.Text = MiAnimal.Debug; else Label1.Text = nombre; Dará como resultado una página html que buscará un animal por su código. En caso de no encontrarlo pondrá el mensaje que arrastra del cs de animal. ERRORES DE EJECUCIÓN Otra posibilidad es que tengamos previsión que en la clase se dé un error. Por ejemplo que no se encuentre un fichero a leer o que la base de datos esté caída. Si esto no Tema 4 / Página 2

3 funciona la aplicación no podrá continuar. En este caso el Debug recogerá algo como No se ha encontrado el fichero buscado en y después lanzará una excepción con un texto tal como fichero no encontrado. Esta excepción tendrá que ser tratada en la página aspx. Para controlar este tipo de errores se usa -catch-finally Cuando queramos controlar una parte del código que puede producir un error lo incluimos dentro del bloque, si se produce un error, éste lo podemos detectar en el bloque catch, por último, independientemente de que se produzca o no una excepción, podemos ejecutar el código que incluyamos en el bloque finally. Cuando creamos una estructura de control de excepciones no estamos obligados a usar los tres bloques, aunque sí el primero. Podemos crear un "manejador" de excepciones usando los tres bloques, usando y catch o usando y finally. Bloque En este bloque incluiremos el código en el que queremos comprobar los errores. En el momento que se produzca el error se usará (si hay) el código del bloque catch. Bloque catch Si se produce una excepción, ésta la capturamos en un bloque catch. En el bloque catch podemos indicar que tipo de excepción queremos capturar, para ello usaremos una variable de tipo Exception, la cual puede ser del tipo de error específico que queremos controlar o de un tipo genérico. // código para trabajar con ficheros, etc. catch(system.io.ioexception ex) // el código a ejecutar cuando se produzca ese error Si nuestra intención es capturar todos los errores que se produzcan podemos usar la clase Exception como tipo de excepción a capturar. Es la más genérica de todas las clases para manejo de excepciones, por tanto capturará todas las excepciones que se produzcan. // código que queremos controlar catch(system.exception ex) // el código a ejecutar cuando se produzca cualquier error La variable indicada en el bloque catch (ex) la podemos usar para mostrar un mensaje al usuario o para obtener información extra sobre el error. Tema 4 / Página 3

4 Pero si no vamos usar la variable indicada en el bloque Catch, pero queremos que no se detenga la aplicación cuando se produzca un error, podemos hacerlo de esta forma: // código que queremos controlar catch // el código a ejecutar cuando se produzca cualquier error Varias capturas de errores en un mismo bloque /catch En un mismo /catch podemos capturar diferentes tipos de errores, para ello podemos incluir varios bloques catch, cada uno de ellos con un tipo de excepción diferente. Es importante tener en cuenta que cuando se produce un error y usamos varios bloques catch, el CLR de.net buscará la captura que mejor se adapte al error que se ha producido, pero siempre lo hará examinando los diferentes bloques catch que hayamos indicado empezando por el indicado después del bloque, por tanto deberíamos poner las más genéricas al final, de forma que siempre nos aseguremos de que las capturas de errores más específicas se intercepten antes que las genéricas. En el siguiente código capturamos un error específico y también uno genérico, con idea de que tengamos siempre controlado cualquier error que se produzca: // código que queremos controlar catch(formatexception) // captura de error de formato catch(exception ex) // captura del resto de errores Bloque finally En este bloque podemos indicar las instrucciones que queremos que se ejecuten, se produzca o no una excepción. De esta forma nos aseguramos de que siempre se ejecutará un código, por ejemplo para liberar recursos, se haya producido un error o no. Nota: Tema 4 / Página 4

5 Hay que tener en cuenta de que incluso si usamos return dentro de un bloque de control de errores, se ejecutará el código indicado en el bloque finally. Ejemplo: using System; public class Util private string _debug; public string Debug get return _debug; public string Lee() const string fic string texto; System.IO.StreamReader sr = new System.IO.StreamReader(fic); texto = sr.readtoend(); sr.close(); catch (Exception e) _debug += "Fichero " + fic + " no encontrado " + e.message; throw new Exception("Fichero no encontrado"); finally //Para cuando necesite cerrar algo return texto; Y en el cs asociado a nuestro aspx pondremos: protected void Page_Load(object sender, EventArgs e) Util miutil = new Util(); string texto = miutil.lee(); Label1.Text = texto; catch throw new Exception ("ERROR " + miutil.debug); Pero evitaremos que de un error de color amarillo en la pantalla del usuario. Por ello trataremos al error según se explica en el punto siguiente. Tema 4 / Página 5

6 3. ERRORES EN CLASES CS ASOCIADOS A ASPX Para tratar ambos errores (lógicos y de ejecución) vamos a seguir las siguientes pautas: 1.- Incorporamos la referencia ClaseErrores.dll de la carpeta ToolsNet/DLL. 2.- Incorporamos global.aspx y ponemos en la segunda línea: <%@ Import Namespace="ua" %> Y en la sección de application_error: void Application_Error(object sender, EventArgs e) // Código que se ejecuta al producirse un error no controlado ClaseErrores mierror = new ClaseErrores(true); // Si ponemos false no se ofrecerá información sobre la pila // Si ponemos ClaseErrores(true, true) obligamos a enviar el error por correo. 3.- Como estamos en un entorno local deberemos crear una carpeta ToolsNet dentro de nuestro sitio web. Dentro pondremos un fichero ruta.xml. Ese fichero contendrá: <?xml version="1.0" encoding="utf-8"?> <ERRORES actualizado="8/24/2009"> <PATH path="~" descripcion="ejemplo" id="9"> < idhijo="5">direccion.correo@ua.es</ > </PATH> </ERRORES> ERRORES DE EJECUCIÓN Ahora si se produce un error de ejecución como throw new Exception ("ERROR " + miutil.debug); se pintará en pantalla un mensaje como: Tema 4 / Página 6

7 En caso de estar en un entorno de producción (o de haber obligado a enviar el error por correo) ese mensaje se enviará al correo indicado y en pantalla se mostrará el típico Error inesperado. ERRORES LÓGICOS Podemos generar errores cuando algo inesperado ocurra, pero que no hace falta que se corte el flujo del programa. Por ejemplo, si el usuario que se está buscando no se encuentra se puede indicar con un mensaje. Y nos puede interesar que ese error se envíe por correo. using System; using ua; public partial class _Default : System.Web.UI.Page ClaseErrores mierror = new ClaseErrores(); protected void TextBox1_TextChanged(object sender, EventArgs e) ClaseAnimal MiAnimal = new ClaseAnimal(); string nombre = MiAnimal.Carga(int.Parse(TextBox1.Text)).Nombre; //El programa continua y envía error ControlError.PararEnviaError = false; //La variable debug me sirve para determinar si todo ha ido ok if (MiAnimal.Debug!= null) //Determina si el error se envia por correo mierror.envio = true; //Se envia correo y se para la ejecución del programa mierror.enviaerror( "El usuario esta buscando " + TextBox1.Text, -1000); else Label1.Text = nombre; Si añadimos ControlError.PararEnviaError = false; convertimos el error en una aviso, es decir, que el error no saldrá en la ejecución del programa pero se enviará por correo al programador. Tema 4 / Página 7

8 4. ENLACES INTERNET Sobre manejo de excepciones: Sobre el componente claseerrores.dll 5. EJERCICIO Incorporar la gestión de errores en la aplicación. Se proponen estos pasos: 1.- Incorporar la librería ClaseErrores.dll de ToolsNet. 2.- Copiar a una carpeta ToolsNet de nuestro sitio web ruta.xml y modificar el correo electrónico. 3.- Incorporar un global.aspx y arreglar el application_error. 4.- En claselocalizaciones incorporar una propiedad de solo lectura Debug. Controlar los posibles errores de conexión de base de datos. 5.- En claseusuario incorporar una propiedad de solo lectura Debug. Controlar posibles errores de conexión de base de datos, de no localización de un usuario, de no poder insertar un usuario y de no poder borrarlo. 6.- En el cs asociado al aspx mostrar estos errores en ContentPlaceHolderNoticias. Estos errores serán sensibles al idioma. 7.- En claselocalizaciones incorporar una propiedad de solo lectura Debug. Controlar los posibles errores de conexión de base de datos. Tema 4 / Página 8