Guía básica de depuración de código xcode 6 apple coding

26/4/2015 Guía básica de depuración de código Xcode 6 | Apple Coding
http://applecoding.com/guias/guia-basica-depuracion-codigo-xcode-6-debug 1/6
Guía básica de depuración de código en Xcode 6
 Julio César Fernández  Guías  327 Lecturas
Una de las partes imprescindibles de todo desarrollo es la depuración del código, proceso que podríamos
dividir en dos partes bien diferenciadas: interpretar los fallos que nos da el sistema y ser capaz de
monitorizar nuestro código para localizar comportamientos no deseados en el mismo.
La presente guía, aunque se ilustra en Swift, funciona igual si trabajamos en Objective-C. Hemos de tener
en cuenta que estamos hablando de funciones del propio Xcode y del depurador LLDB que forma parte
del compilador LLVM, por lo que en este caso el lenguaje que usemos es indiferente. De hecho, si nuestro
proyecto mezcla ambos lenguajes o usa otros como C++, servirá igualmente todo lo que aquí
explicado.
Entendiendo los errores
EXC_BAD_INSTRUCTION, SIGABRT, EXC_BAD_ACCESS… ¿le suenan, verdad? Son algunos de los errores
genéricos que nos encontraremos en nuestro trabajo, muchos de ellos difíciles de entender cuando el
código mostrado ni siquiera es nuestro y no sabemos a qué se está refiriendo. Pues bien, veamos por
qué sucede cada uno de estos:
EXC_BAD_INSTRUCTION: En el 99% de las veces este error es generado de manera intencionada. Es
decir, un assertion o instrucción que provoca un error fatal para prevenir que la aplicación entre en un
estado que no debería. Imaginen que tenemos un app que nada más arrancar carga una base de datos y
Otras recomendaciones
Guía: documentando tu código en
Swift
Guía paso a paso de cómo generar
documentación para tu código en Swift, con
el objetivo de ayudarte a mantenerlo,
consultarlo y trabajar en equipo. Consíguelo
de una manera rápida, intuitiva y marca y
clasifica el código para facilitar tu trabajo y
el de los demás, con unos sencillos y
prácticos pasos.



ponemos su nombre para cargarla. Si lo hemos puesto mal y el archivo no existe, la librería de base de
datos es probable que provoque uno de estos errores para evitar que la app arranque porque si no hay
base de datos la app directamente no funcionará.
SIGABRT: Un error de este tipo se provoca por un excepción de código porque se quiere hacer o acceder
a algo que no se puede. Por ejemplo, cuando una clase recibe la llamada a un método o un mensaje que
no existe, como un Selector que no existe.
EXC_BAD_ACCESS: Cuando nos indica que intentamos acceder a la dirección 0x0, es porque estamos
intentando acceder a una zona de memoria errónea, por ejemplo, a la dirección nil. Este puede
provocarse por intentar acceder a un objeto que en ese momento ya ha sido liberado de memoria (este
podría ser un posible caso). Estos pueden ser difíciles de trazar y solventar.
Hay determinados errores que son muy descriptivos a la hora de ser mostrados y que nos dicen
exactamente cuál es el problema: un método que no existe en una clase, un valor incorrecto en una
variable de un tipo determinado, un opcional desempaquetado que devuelve un valor nil, etc. Pero hay
otros que directamente nos llevan al main del programa y tienes que ponerte a buscar tú qué ha fallado.
Vamos a intentar dar algunos pasos básicos para intentar solventar y monitorizar los fallos.
Swift, un nuevo paradigma
Los errores en Swift, durante la ejecución, son mínimos. Uno de los motivos principales de la existencia de
este, es que muchos de los errores de codificación que se tienen en Objective-C u otros lenguajes que se
usan con Xcode suceden durante el flujo de ejecución lo que hace que (curiosamente) las apps de iOS
sean menos estables estadísticamente hablando que las de Android. Y no tiene nada que ver con el
sistema operativo, si no con la calidad del código y las herramientas que este tiene en su estructura
para trasladar los fallos del ciclo de ejecución al ciclo de codificación o al de compilación.
En Swift, por ejemplo, se evalúa la tipificación de los datos y su contenido. De esta forma, si algo se pone
donde no se debe o algún objeto tiene la posibilidad de estar vacío cuando no debería en el transcurso de
la ejecución del programa, en el nuevo lenguaje tenemos herramientas que nos alertan de estos
problemas y nos obligan a utilizar estructuras (como las opcionales) que trasladan los errores al momento
de la codificación o de la compilación, pero no al de la ejecución que es donde se provocan los
problemas de estabilidad de las apps.
Pero, por otro lado, aunque Swift sea un lenguaje con un estructura completamente segura que evita en
un 99% los errores en tiempo de ejecución (trasladando estos a compilación o codificación, como hemos
dicho), también es cierto que muchas de las APIs que usamos en un programa en Swift no están en
dicho lenguaje, tanto a nivel de terceros como las propias librerías del sistema. Y aquí, sí pueden

provocarse problemas. De hecho, por eso Apple está migrando sus librerías principales del sistema, como
la propia Cocoa, a Swift: con el fin de aumentar la eficiencia y la seguridad de los desarrollos.
Trazando un error
Cuando tenemos un fallo y nuestro programa se cuelga, lo que tenemos a la izquierda es una lista del
contenido de cada hilo de ejecución, a la derecha el código y el lugar donde se ha parado (que muchas
veces no es el sitio real donde se provocado el error). Debajo se divide en dos partes: a la izquierda el
contenido de la memoria en el hilo donde estemos y la derecha la salida en modo terminal del
compilador y la consola del depurador.
Lo primero que hemos de hacer es analizar qué ha pasado, y eso podemos hacerlo revisando el tipo de
error que tenemos. Si es un SIGABRT o cualquiera de los otros errores que hemos comentado tendremos
una idea más clara de qué ha pasado. Igualmente, puede que la descripción del error nos de más
información como unrecognized selector sent to instance, por ejemplo, que nos indica que hemos
llamado a un método de un clase que no existe.
El siguiente paso es analizar la información de los hilos relacionados con el error. Si nos vamos a la
ventana de LLDB (el depurador del compilador LLVM) situada abajo a la derecha, veremos el error y luego
un escueto (lldb) en color más claro. Si pulsamos ahí, veremos que podemos escribir. Vamos a
inspeccionar el contenido del hilo donde se ha parado y que tenemos en la lista de la izquierda, el 1.
f 1
La instrucción f o frame (ambas instrucciones sirven) nos mostrará la información del hilo y nos dará
mayor información sobre dónde se ha parado este. Mirando uno a uno podemos trazar paso a paso
dónde ha ocurrido el error y buscar su origen. Vemos que está señalando con un -> la línea 57 que es
donde hemos llamado a inicio! siendo inicio un opcional no inicializado con un valor.

thread info 1
Ahora obtenemos más información aun que nos dice claramente que el error procede de la librería
principal del lenguaje Swift, libSwiftCore.dylib.
(lldb) thread info 1
thread #1: tid = 0x32436, 0x0272e327 libswiftCore.dylib`function signature specialization <Arg[0] = Exploded, Arg[1] = Exploded, Arg[2] = Dead, Arg[3] = Dead>
Podemos pulsar en los hilos directamente en la parte de la izquierda. Si vemos que hay algunos a los que
no podemos acceder (por ejemplo, que del 4 salta al 23) podemos pulsar en el pequeño botón situado
abajo a la izquierda (muy pequeño) que es un cuadrado con dos líneas rectas una debajo de otra. Al
hacerlo, podremos ver todos los hilos.
Puntos de ruptura o breakpoints
Los breakpoints son un elemento esencial de cualquier depuración de código. Vamos a ir a una línea
cualquiera donde queramos que la ejecución de nuestra aplicación se pare: vemos que hay un pequeño
hueco entre la ventana del código y la línea que separa el navegador. En esa línea, podemos pulsar y
veremos que aparece un pequeño rectángulo con punta a la derecha de color azul: ya hemos creado un
punto de ruptura o breakpoint.
Cuando ejecutemos la aplicación, al llegar a este lugar la aplicación se interrumpirá como si fuera un
error sin serlo. En ese momento, podremos examinar el estado en que está, consultar los valores que
estén en memoria en ese momento y mucho más.
A la izquierda del depurador LLDB
tenemos la ventana con los
elementos que hay en memoria.
En self están todas las
propiedades y valores que pertenecen a la clase donde nos hemos parado y si desplegamos veremos un
listado con lo que contiene y sus valores. Si por ejemplo, uno de los valores es un array podemos
desplegar y ver los diferentes valores que tiene. Lo mejor es que nos movamos y curioseemos para ver
qué información podemos mirar. También, por ejemplo, podemos pedir el valor de una variable con el
comando p en el depurador.
Como vemos en el ejemplo más arriba, ponemos p y el nombre de la variable y se nos muestra su
contenido, como si estuviéramos con el REPL del lenguaje.
Mientras estemos depurando el código tenemos que prestar atención a los botones que vemos

más arriba. El de la izquierda del todo despliega u oculta la ventana, el siguiente (el símbolo de los puntos
de ruptura) nos permite habilitar o deshabilitar todos los puntos que tengamos en la app y el tercero nos
permite parar la ejecución de un programa cuando queramos y revisar su contenido.
Los tres siguientes nos permiten navegar: Step Over, Step Into y Step Out. El primero avanzará línea a
línea la ejecución, pero en las llamadas a métodos o funciones simplemente recuperará su valor sin entrar
en ellos. Con Step Into sí entraremos en los métodos y funciones, alterando el flujo de ejecución, y Step
Out nos permite salir del contexto donde estemos en ese momento (un método o función) o de un bucle.
Editar los puntos de ruptura
Si hacemos CMD+click o click secundario en el punto de ruptura (en el cuadrito azul con punta a la
izquierda del código) veremos una serie de opciones que nos permitirán habilitar o deshabilitar el
punto o editarlo.
Si lo editamos podemos hacer algunas cosas muy prácticas como condicionar que el punto de ruptura
detenga el programa si la condición que ponemos se cumple, que se ignore un número de veces que
queramos el salto de este punto, añadir una acción como un comando del depurador e incluso hacer que
una vez salte el punto de ruptura, la ejecución del programa continue tras evaluar las condiciones
sin detenerse y mostrar algún valor, por ejemplo.
Imaginad que tenemos un bucle de 200 vueltas y
queremos que el punto salte cuando haya
superado los 100 primeros. Ponemos la condición
y luego podemos decirle mediante el comando p
que nos muestre el valor de una variable. Si
marcamos que continúe tras evaluar la condición
conseguiremos que nos muestre el valor de esta sin necesidad de incluir nosotros ninguna
instrucción extra en el código como un NSLog.
Manejar estos puntos de ruptura nos permite hacer muchas cosas y controlar aun mejor qué hace
nuestro programa y por qué se comporta de una manera u otra que tal vez, se escape a lo que
queremos.
Resumiendo
Hemos visto cuáles son los errores básicos que podemos encontrarnos en un programa, cómo
revisar la información de depuración, controlar el flujo de ejecución y crear puntos de ruptura que nos
permitan analizar los datos en cualquier momento para buscar con mayor eficiencia dónde pueden estar

los errores.
La depuración puede hacerse tanto desde el Simulador como directamente con un dispositivo
(aunque para esto último tenemos que ser desarrolladores registrados de un programa de pago). La
mejor forma de aprender es practicar, probar y usar mucho esta herramienta para ir cogiendo soltura. Sin
duda os será de gran ayuda. Practicad mucho y si tenéis cualquier duda, no dudéis en escribirnos o
comentarlo en el post. Good Apple Coding.
Compártelo:
Facebook 10 Twitter 5 Google LinkedIn 16 Pocket Correo electrónico     

Guía básica de depuración de código xcode 6 apple coding

Más contenido relacionado

La actualidad más candente (18)

Destacado (20)

Similar a Guía básica de depuración de código xcode 6 apple coding (20)

Último (20)

Guía básica de depuración de código xcode 6 apple coding