Ediciones ENI Editorial | líder en informática
Depuración y gestión de errores
Los distintos tipos de errores
Ningún software está exento de errores y ningún desarrollador escribe código sin cometer la más mínima falta de sintaxis u olvidarse de un punto y coma. A pesar de toda la atención que pueda prestar un desarrollador en su código, estos errores son inevitables. Es necesario, por tanto, poder identificarlos y corregirlos.
1. Errores de compilación
Los errores de compilación son errores que impiden la generación de un ensamblado a partir del código. Estos errores son, a menudo, errores de sintaxis, pero pueden también estar vinculados a un mal uso de un objeto, de un método o de cualquier otro elemento del código.
Estos errores se detectan en tiempo de compilación, evidentemente, pero también durante la escritura de un programa. En efecto, Visual Studio analiza el código de manera permanente para proveer la máxima cantidad de información lo antes posible, lo que disminuye la dificultad y el coste de corregir cada uno de los errores.
Visualización en la ventana de edición
Los errores detectados por el análisis permanente se muestran directamente en la ventana de edición. Las secciones de código que generan errores están marcadas con un subrayado de color rojo. Es posible ver, también, un cuadro con información detallada acerca...
Uso de excepciones
La generación de una excepción permite interrumpir el flujo normal de ejecución de la aplicación proporcionando información acerca del error que representa. Sin intervención alguna por parte del desarrollador para gestionarla, se propaga automáticamente a través de la pila de llamadas hasta el punto de entrada de la aplicación e incluso puede ocasionar su cierre.
1. Creación y generación de excepciones
Las excepciones se representan mediante objetos que heredan de la clase System.Exception. Pueden generarse (producirse) en cualquier lugar de la aplicación.
a. La clase Exception
La clase System.Exception es la clase de base de la que heredan todas las excepciones. Sus miembros le permiten contener mucha información relativa al error en curso de propagación. La mayoría de estos miembros obtienen valor automáticamente cuando se produce una excepción. Entre ellos encontramos, en particular, la propiedad StackTrace que contiene información particularmente interesante para localizar el origen de la excepción.
La instanciación de un objeto de tipo Exception puede llevarse a cabo mediante tres constructores:
public Exception();
public Exception(string message);
public Exception(string message, Exception innerException); El parámetro message se corresponde con una etiqueta personalizada que permite comprender el error cuando se está tratando lejos de su origen. Es posible recuperar este mensaje más adelante consultando la propiedad Message de la excepción.
El parámetro innerException permite encapsular una excepción que se está tratando en una nueva excepción generada.
b. La palabra clave throw
Instanciar un objeto de tipo Exception no basta para producir una excepción. Para ello, es necesario ejecutar una instrucción throw proporcionando el objeto Exception que se desea elevar.
public void ContarHasta(int número)
{
if (numero < 0)
{
string mensaje = string.Format("Es imposible contar
de 0 a {0}", numero);
Exception error = new Exception(mensaje);
throw error;
}
...Las herramientas proporcionadas por Visual Studio
Las causas de errores lógicos pueden ser particularmente delicadas de controlar. Visual Studio proporciona, por este motivo, una serie de herramientas que permiten controlar el estado de la ejecución de la aplicación, situar puntos de interrupción o visualizar los datos manipulados por la aplicación en tiempo de ejecución.
1. Control de la ejecución
Para poder explorar el código de cara a buscar la causa de un error de ejecución o un error lógico es importante poder controlar la ejecución de una aplicación en condiciones que permitan realizar esta exploración. Visual Studio integra esta posibilidad mediante el uso de un depurador.
En Visual Studio, un proyecto se puede encontrar en tres estados distintos:
-
En modo de diseño: el desarrollo está en curso.
-
En ejecución: el código se compila y la aplicación se ejecuta y se asocia al depurador integrado.
-
En pausa: el depurador ha detenido la ejecución de la aplicación entre dos instrucciones.
a. Arranque
La ejecución de la aplicación en modo de depuración (Debug en Visual Studio) se realiza haciendo clic en el botón Iniciar de la barra de herramientas.
También es posible ejecutar la depuración pulsando la tecla [F5] del teclado.
La combinación de las teclas [Ctrl][F5] ejecuta la aplicación en modo normal sin asociarla al depurador de Visual Studio. El proyecto sigue en modo de diseño, pero es imposible compilarlo o ejecutarlo mientras no se cierre la aplicación.
Cuando la solución contiene varios proyectos, el proyecto generado y ejecutado es el que se ha definido como proyecto de inicio. Es necesario, también, que este proyecto genere un archivo ejecutable. En caso contrario, se muestra un error:
b. Detención
Cuando el proyecto está en modo de ejecución o en pausa es imposible detener completamente su ejecución para pasar de nuevo al modo de diseño. Esta acción se realiza haciendo clic sobre el botón de detención que aparece en la barra de herramientas en modo de ejecución o en pausa.
La información que aparece sobre este botón indica que la combinación de teclas [Mayús][F5] detiene también la ejecución de la aplicación...
El error de un millón de dolares: las referencias nulas
Hemos visto la existencia de referencias nulas en el capítulo Las bases del lenguaje (sección Tipos valor y tipos referencia). Como recordatorio, se corresponden con el estado de una variable de tipo por referencia que no tiene valor.
Se introdujeron por primera vez en 1965 en el lenguaje ALGOL. Su creador, Tony Hoare, ha llamado públicamente a su "invención" una "mala idea histórica" debido al coste desorbitado que han tenido en la industria del desarrollo. Incluso se atrevió a dar una estimación aproximada en una conferencia celebrada en Londres en 2009: ¡entre mil y 10 mil millones de dolares! Y estos valores probablemente todavía están por debajo de la realidad...
El vídeo de la conferencia está disponible en la siguiente dirección: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ (en inglés)
Aunque pueden ser extremadamente prácticas en el día a día, las referencias nulas tienen un gran inconveniente: se deben tener en cuenta en todas partes. Cualquier descuido puede resultar rápidamente en una excepción específica, conocida en el mundo .NET como NullReferenceException. Este tipo de error es probablemente el que más encuentran los desarrolladores a lo largo de sus carreras, tanto en el desarrollo como en las aplicaciones de producción. Por esta razón, el equipo del compilador de C # abordó el tema e introdujo el concepto de referencias no nulas con .NET Core 3.0.
1. NullReferenceException
Este tipo de excepción es muy común en todo el ciclo de vida del software por una razón obvia: es extremadamente fácil de producir. De hecho, se lanza una NullReferenceException cuando se intenta acceder a un miembro de un objeto cuyo valor es null. Como ya hemos visto en el capítulo Las bases del lenguaje, todos los tipos por referencia tienen este valor por defecto, lo que deja un cierto número de posibilidades de error. Y si tiene en cuenta que la mayoría de los objetos .NET utilizados en una aplicación "estándar" son del tipo por referencia, puede imaginar fácilmente el nivel de exposición del desarrollador a estas excepciones.
string cadena = null; ...