El Breakpoint

Recuerdo que hace varios años acudí a una conferencia de emprendedores, donde todoexpertos.com se presentaba ante nosotros, pues sus creadores iban a nuestra escuela de telecomunicaciones. David Zaragoza nos decía que su último gran paso consistió en cambiarse a ASP.NET (en su versión 1.1) por sus innumerables ventajas... era en 2003, poco tiempo después de la puesta en marcha de ASP.NET 1.1.

Más tarde y en privado le pregunté, en mi completa ignorancia, qué era lo que más destacaba de ASP.NET. Ante una pregunta tan terriblemente genérica, me dijo que el uso del BreakPoint le había ahorrado más horas de depuración de código que tiempo le había costado aprender C# para ASP.NET.

Y no, la afirmación no es en absoluto exagerada. Con cualquier programa de la familia del Visual Studio podemos usar los BreakPoint, que no son más que puntos que podemos marcar en nuestro código de modo que la ejecución del programa se pare ahí... si ya lo sé, eso se viene haciendo desde los años 90 con los programas de escritorio, pero nunca se había podido hacer con un programa Web.

De este modo, en cualquier parte del ciclo de vida de nuestra aplicación Web podemos colocar un BreakPoint y depurar nuestro código al máximo. Es extremadamente útil cuando tenemos un pequeño error, pero también nos puede servir para otras cosas como el hacerse una idea de la eficiencia temporal de nuestros algoritmos o para vigilar detalles que pueden pasar desapercibidos incluso cuando no hay un error.

Usando el Visual Web Developer (es muy similar para otras versiones del Visual Studio), activar un BreakPoint es terriblemente sencillo, no hay más que hacer click sobre la parte izquierda de la línea donde lo queremos ubicar. Y para ponerlos en marcha no hay más que hacer un debugging (tecla F5).

NOTA: es imprescindible que en vuestro web.config tengáis definido <compilation debug="true" />

Una vez comenzado el debugging, utilizaremos los controles siguientes:

Upload/breakpoint4.jpg

Que de izquierda a derecha los describimos como:
1.- El botón de play reanudará la ejecución cuando ésta haya sido parada por un breakpoint.
2.- Se hará un pause estemos donde estemos.
3.- Pararemos el debugging y la aplicación acabará de ejecutarse ignorando el resto de breakpoints.
4.- Reiniciaremos el debugging desde el principio.
5.- Seguiremos la ejecución hasta el próximo estamento.

Una vez parados en un breakpoint tenemos varias opciones de seguir ejecutando el código y depurarlo:
6.- "Step Into". Iremos a la siguiente línea de código entrando en niveles inferiores. Por ejemplo, si la aplicación está parada sobre la llamada a una función, entraríamos dentro de esa función.
7.- "Step Over". Iremos a la siguiente línea de código, siempre en el mismo nivel. Siguiendo el ejemplo anterior, no se entraría dentro de la función, sino que se seguiría a la siguiente línea del lugar en que estemos.
8.- "Step Out". Viajaremos al nivel superior en que nos encontremos. Por ejemplo, si estamos dentro de la función A, saldremos a la otra función B que en su momento había llamada a la función A.

NOTA: Los botones 6, 7 y 8 resultan especialmente difíciles de explicar, por lo que recomiendo que juguéis mucho con ellos y le saquéis todo el jugo posible.

En nuestro ejemplo vamos a poner dos, uno en el evento "Load" de la página y otro en el evento "Click" de un botón:

Upload/breakpoint1.jpg

Nada más cargar la página, la ejecución se parará sobre nuestro primer BreakPoint, que es la línea en que se le asigna el valor de la variable frase a la propiedad Text de nuestro Label:

Upload/breakpoint2.jpg

Si posamos el ratón sobre la variable frase, veremos una pequeña ventanita donde observaremos el valor de dicha variable. En este punto, si posaramos el ratón sobre la propiedad Text de nuestro Label, observaríamos que el campo está vacío, pues la ejecución se para antes de ocurrir la asignación.

Cuando hacemos click en el botón de nuestra página se ejecutará nuestro algoritmo, que consiste en contar los múltiplos de 7 que hay entre 1 y 20. La impresión de pantalla corresponde con el segundo paso por el breakpoint:

Upload/breakpoint3.jpg


Como vemos, si tenemos activa nuestra ventana "Locals" dispondremos de completa información de todas las variables que están en juego en el momento el código llega a nuestro breakpoint. Como podemos observar, i  = 14, y contador = 1 (correspondiente al momento en que i valía 7). Cuando sigamos con la ejecución del programa contador se autoicrementará y finalmente nuestra label mostrará su valor final (2).

Este no ha sido más que un sencillísimo ejemplo del que se pueden extraer pocas conclusiones... incluso así, a la hora de ejecutar el ejemplo, me he dado cuenta de que al hacer click sobre el botón se volvía a ejecutar el primer BreakPoint... deberíamos haber usado el Page.IsPostBack!

La utilidad del BreakPoint se incrementa exponencialmente cuando estamos trabajando con XML, con llamadas a BBDD, pues podemos seguir paso a paso la ejecución de los algoritmos, el valor detallado de nuestras variables, etc.