Etiqueta: Debugging

Cuando estás comenzando con php es muy común encontrarte ante alguna situación similar a esta:

«por algún motivo no puedo insertar datos ni actualizar ni borrar.
Me da un error en las lineas 51 y 52″

«estoy queriendo insertar un string en una base de datos pero me da error, no me reconoce el formato de la hora»

«estoy haciendo un select php con un where, pero no me muestra los resultados, me da error.»

Seguramente te estarás preguntando qué puede estar pasando y más importante: ¿¿cómo resolverlo??

Hay pocas cosas más desesperantes que probar y probar y que nada funcione…

Te tengo buenas noticias: la solución está más cerca de lo que parece.

Lo primero que hay que hacer en una situación como esta es respirar hondo, tal vez dar una pequeña vuelta alrededor del escritorio y volver con la cabeza más fresca.

Una vez pasada la desesperación tenés que comprender algo fundamental:

No todos los errores son iguales

Con esto quiero decir que «me da error» ayuda poco cuando se trata de encontrar una solución.

Hay que comprender la causa del problema para avanzar.

Es como cuando vas al médico: si todo lo que el profesional sabe es que te sentís mal es difícil que te pueda curar.

Cómo encontrar la causa del error

Lo primero que necesitás es comprender exactamente cuál es el error.

Usualmente, cuando un programa no completa su ejecución, en algún lado se guarda información de qué fue lo que sucedió.

Dependiendo de la configuración es posible que esa información esté directo frente a tus ojos, a través de un mensaje de error en la pantalla:

O que se esconda detrás de un mensaje algo genérico como:

En este caso no significa que esta es toda la información que vas a obtener, sólo que vas a tener que buscar un poco más, probablemente en los archivos de log del servidor web.

Los mensajes pueden parecer un poco difíciles de leer e interpretar, especialmente si no sabés inglés, pero si les prestás atención notarás que son muy informativos.

Cerca del 80% de los errores de php se pueden comprender simplemente leyendo el mensaje. Compartir en X

Veamos algunos ejemplos.

Call to undefined function

Fatal error: Uncaught Error: Call to undefined function sqlsrv_query() in /home/mauro/Code/sunat/cambio.php on line 4

Desmenucemos un poco el mensaje.

La primera parte dice Fatal error.

Suena feo ¿no? Error fatal… tranquilo, no se murió nadie, simplemente significa que se ha producido un error que impide que el script siga ejecutándose.

Luego vemos que dice Uncaught error.

Uncaught significa «no atrapado», lo que da una idea de que los errores pueden atraparse… tema un poco avanzado para este momento, por lo pronto dejémoslo de lado.

Y ahora sí llegamos a la parte jugosa: Call to undefined function sqlsrv_query().

Este es realmente el problema: se está intentando llamar a una función que no ha sido definida aún (o al menos, el intérprete no la conoce).

¿Cuál es la función desconocida? sqlsrv_query.

En php existen dos tipos de funciones:

1. Propias del lenguaje (o de librerías escritas en C)
2. Definidas por el programador (vos)

El caso de sqlsrv_query es el primero, pero si intentaras llamar a una función tuya que el intérprete desconoce el problema sería el mismo.

Así que aquí tenemos la primera pista.

Luego tenemos otros dos datos muy importantes:

in /home/mauro/Code/sunat/cambio.php

Está indicando cuál es exactamente el archivo que se estaba ejecutando cuando el problema se presentó.

Por último on line 4 te está indicando cuál fue exactamente la línea que disparó el error.

Con todo esto tenés bastante de dónde agarrarte: sabés qué línea de qué archivo tenés que ir a mirar… no está mal, ¿cierto?

Ahora vamos al caso específico.

Si no sabés mucho sobre la función sqlsrv_query siempre tenés un aliado poderoso: el viejo y querido Google.

Una búsqueda simple te va a dar estos resultados:

Y ya que apareció un link a la página oficial de php.net, yo te diría que lo sigas a ver qué aparece :).

Leyendo un poco vas a encontrar que la función sqlsrv_query pertenece a la extensión SQLSRV.

Como el resto de las extensiones, puede ser habilitada o deshabilitada en la configuración de PHP (el famoso archivo php.ini).

Así que una posibilidad es que la librería no esté instalada y/o habilitada.

Sólo lo vas a saber mirando cómo está tu instalación de php.

Undefined variable

Notice: Undefined variable: ejecutar in C:\wamp\www\demo\php\insertar.php on line 19

Acá lo que está diciendo el intérprete está diciendo:

1. Que hay una variable no definida llamada ejecutar (Undefined variable: ejecutar)
2. Que el problema aparece en la línea 19 del archivo C:\wamp\www\demo\php\insertar.php

Momento.

¿No era que en PHP no hacía falta definir las variables?

¿En qué quedamos?

Sin ver el código completo puedo inferir que en la línea 19 se está intentando usar esa variable antes de haberla asignado en algo como:

<?php

if ( $ejecutar == 'Otro ejemplo:algo' ) ...

En php la definición y la primera asignación de una variable se producen en el mismo momento.

Otro detalle interesante para notar es que el mensaje comienza con Notice (A diferencia del anterior que empezaba con Fatal Error).

PHP tiene diferentes niveles de errores, algunos más graves que otros.

Según el tipo específico del error se disparará (o no) alguna acción, como por ejemplo finalizar la ejecución del script ante la detección del error.

Object of class … could not be converted to String

Catchable fatal error: Object of class DateTime could not be converted to string

Aquí lo que está sucediendo es que se está tratando de usar un objeto de tipo DateTime en el contexto de un string… y la clase DateTime no tiene un método __toString.

Un código que podría dar este problema es:

<?php

echo 'Hoy es '.(new DateTime()).'!';

Qué hacer cuando el mensaje de error no alcanza

Claro que no siempre la vida es tan generosa… ¿Qué pasa cuando el mensaje de error no es suficiente?

¿Qué podés hacer?

Bueno… sí, es una opción, pero existen algunas mejores opciones 🙂

A veces sucede que encontrar la causa de un error requiere algo más que simplemente leer el código.

Esto sucede, por ejemplo, cuando el programa falla a veces

Tomemos un código como este:

<?php

$a = rand(1,3);

switch ($a) {
case 1:
        echo 'Hoy es: '.(new DateTime());
        break;
case 2:
        echo $a;
case 3:
        echo $a * 2;
}

echo PHP_EOL;

Estadísticamente este programa debería fallar una de cada 3 veces que es ejecutado.

¿Cuándo? Cada vez que $a == 1.

Y ¿cómo podés saber cuánto vale $a en cada ejecución?

Necesitás alguna herramienta que te permita ver su contenido.

Existen diferentes opciones:

• var_dump
• echo
• print_r

Pero la realidad es que la mejor alternativa es no usar ninguna de ellas, si no más bien un debugger.

Qué es un debugger

Un debugger es un programa que te permite ejecutar tu código paso-a-paso.

Es decir, en lugar de correr el programa entero y, recién entonces, ver la salida y tratar de entender qué valor tenía cada variable al momento de la ejecución, con el debugger podés ver el contenido de tus variables en tiempo real.

Los más populares para PHP son

• XDebug (Mi favorito)
• ZendDebugger

Si querés conocer más sobre cómo usar un debugger en tus aplicaciones podés seguir leyendo acá.

Si PHP te da errores no corras

La próxima vez que te encuentres ante un error de PHP (Y creeme, te va a pasar), no te desesperes.

Tomá un poco de aire y hacé un pequeño esfuerzo por comprender el mensaje de error que estás viendo.

Te sorprenderá la cantidad de veces que no necesitarás más para subsanar el problema 🙂

Cuántas veces te pasó que te mande un mail un cliente (o peor, te llame por teléfono) para decirte que la aplicación que pusiste en producción hace más de una semana acaba de dar uno de esos errores inentendibles:

Y vos, estando en cualquier otro tema tenés que buscar en lo más recóndito de la memoria para recordar de qué se trataba y contestar algo medianamente coherente…

¿No sería genial poder decirle a tu cliente apenas atender: «Sí, ya sé, hubo un problema con la app, ya lo estoy viendo y enseguida lo tenés solucionado»?

Hay varios puntos para señalar en este escenario:

1. Más allá de que «queda feo» que un cliente vea un mensaje en inglés cuando el resto de la aplicación está en castellano (o que vea una pantalla con fondo blanco y despojada de todo branding), esto da a un potencial atacante información que no tiene por qué tener: que tu aplicación está desarrollada usando Symfony¹ (y por lo tanto PHP).
2. Se pierde un tiempo valioso buceando en los logs de errores hasta entender qué pudo haber pasado. Asumiendo que tales logs existan, claro.

Algo que mejora tanto la seguridad de la aplicación como la experiencia del usuario es simplemente contar una página de error personalizado:

Fácilmente puede especificarse qué hacer en caso de que la respuesta a enviar no sea un código 200 usando configuración de Apache, NginX o el webserver que sea.

En este post te voy a mostrar cómo lograrlo sin tocar nada desde la infraestructura, si no todo dentro de tu propio proyecto.

Lo voy a hacer usando el framework Symfony. Si estás usando otro no va a ser tan literal el tema, pero las ideas te servirán igual:

En Symfony los errores HTTP se manejan mediante Excepciones, para cada tipo de error existe un template que se utiliza para generar la respuesta a enviar.

Todo esto en realidad no es de Symfony si no de Twig (el motor de templating que viene junto con el framework).

Dentro del código de una aplicación Symfony típica vas a encontrar un directorio vendor/symfony/symfony/src/Symfony/Bundle/TwigBundle/Resources/views/Exception/ donde se encuentran los templates usados en caso de error.

Como en cualquier otro caso en que necesites modificar comportamientos estándar de los bundles, lo más conveniente es crear tu propia copia de los archivos originales dentro del directorio app/Resources de tu aplicación. En este caso sería el directorio app/resources/TwigBundle y dentro de él views/Exception/

Hasta aquí resolvimos el problema de lo que el usuario ve pero… ¡todavía sos el último en enterarse de lo que pasó!

Bien… ¿cómo podrías enterarte de algo que está sucediendo en el servidor sin estar pegado al log de errores 24×7?

¿Qué tal una alerta por email?

Lo primero que podrías pensar es en codear tu propio mecanismo de envío de correos ante la aparición de un error… y por ahí hasta lo lograrías. Pero, como nos gusta decir por aquí, ¿para qué reinventar la rueda?

¿Te acordás de lo que te conté sobre Monolog? Vamos a ver cómo se puede usar una de sus características más interesantes: la composición de loggers (o handlers en terminología Monolog).

De lo que se trata acá no es ni de reemplazar el logging tradicional por el mail ni de llenarte la casilla de mensajes crípticos, si no de tener lo mejor de ambos mundos (Una alerta a tiempo con la información necesaria para reaccionar y los logs completos donde deben estar).

Una forma de lograr esto es usando inteligentemente la configuración Monolog y de SwiftMailer. Estas configuraciones las encontrás en el archivo app/config/config.yml(y por supuesto en sus hijos config_dev.yml y config_prod.yml).

Del lado de Monolog debería quedar algo como:

monolog:
    handlers:
        main:
            type:         fingers_crossed
            action_level: error
            handler:      grouped
        grouped:
            type:       group
            members:    [streamed, deduplicated]
        streamed:
            type:  stream
            path:  %kernel.logs_dir%/%kernel.environment%.log
            level: debug
        deduplicated:
            type: deduplication
            handler: swift
        swift:
            type:           swift_mailer
            from_email:     app@dominio.com
            to_email:       mauro.chojrin@leewayweb.com
            subject:        "App::Error_Exception"
            level:          error
            formatter:  monolog.formatter.html
            content_type: text/html
        console:
            type:  console

Lo que estamos haciendo acá es decirle a Monolog (a través del sistema de configuración de Symfony) que cada mensaje debe ser procesado por el handler grouped que, como podrás ver, es de tipo group (Una forma muy elegante de hablar de un conjunto de loggers).

El primero de esos loggers es el clásico: archivo de texto local (Se podría hacer algo más complejo si tuvieses que sincronizar logs de diferentes servidores, pero lo dejamos para otro momento).

El segundo logger es más interesante: deduplicated (Una suerte de filtro para no llenarte la casilla con el mismo mensaje enviado 1000 veces). Este a su vez usa un handler propio: swift.

El handler swift es el que efectivamente se encarga de realizar el envío del error a la casilla que le indiques… en realidad, de lo que se encarga es de pedirle a SwiftMailer que haga todo eso.

Y ahí es donde entra en juego la configuración propia de SwiftMailer… después de todo, esto tampoco es mágico.

Lo más importante acá es a través de qué medio se va a realizar el envío, es decir qué tipo de transport vas a querer usar.

En mi ejemplo usé una cuenta de Gmail creada especialmente para esta aplicación (Total son gratis y andan muy bien :)).

La configuración al final es esta:

swiftmailer:
    host: smtp.gmail.com
    username:  '%mailer_user%'
    password:  '%mailer_password%'
    encryption: ssl
    port: 465

Al usar el username '%mailer_user%' y el password '%mailer_password%' lo que estoy diciendo es que los valores de esta configuración se obtengan del archivo app/config/parameters.yml. Como este archivo es específico para cada entorno donde la aplicación esté desplegada (léase: ¡no lo versiones!), esta configuración permite usar diferentes cuentas para desarrollo y para producción.

Lo único que debés tener en cuenta si vas a usar Gmail (En lugar de algún otro SMTP público) es que vas a tener que permitir el acceso a la cuenta a aplicaciones no seguras.

Por último, para recibir un mensaje que se vea así:

En lugar de así:

Se usan las líneas:

formatter: monolog.formatter.html

content_type: text/html

De la configuración de Monolog.

Y ahora sí, todo listo, si llega a producirse un error inesperado, el mismo sistema te va a avisar con un email bien formateado.

Y si todavía querés llevar el tema a un nivel superior, una herramienta sumamente interesante que te recomiendo usar es Honeybadger.

Con Honeybadger podés tener un panel de administración donde se centralicen todos los problemas u otros mensajes que quieras que tu aplicación envíe.

De esa forma, la gestión de los problemas puede hacerse todavía más eficiente.

Te recomiendo que le des una mirada.