¿Qué sería de la Web 2.0 sin la Fail Whale o las páginas de error 404 personalizadas? Es una práctica tan extendida que ya casi constituye una norma no escrita del desarrollo web: proveer al usuario de páginas de error que no sólo le informen de lo que está pasando sin perder la referencia de dónde está (es decir, totalmente integrada dentro de la estructura y el diseño de nuestro site), sino que además sean divertidas o por lo menos un tanto adorables, para aliviar el mal trago que supone el toparse de bruces con un error del protocolo HTTP. Por suerte para nosotros, en Symfony2 el proceso de personalizar las páginas de error es realmente sencillo e intuitivo.
Como siempre, el primer paso debería ser echarle un ojo a la propia documentación oficial para ver qué novedades nos trae Symfony2. Como veremos, no son pocas: además de la página de error estándar de HTML, Symfony2 viene con una página de error por defecto para la mayoría de los formatos de respuesta más comunes tales como JSON (error.json.twig), XML (error.xml.twig), Javascript (error.js.twig) y CSS (error.css.twig) y también otros menos comunes como TXT, RDF, y ATOM. Todas estas pantillas de error por defecto se encuentran dentro del FrameworkBundle. Si queremos substituir estas páginas por defecto por las nuestras personalizadas, simplemente debemos crear un archivo con el mismo nombre dentro de nuestro app/Resources/FrameworkBundle/views/Exception, es decir, siguiendo el procedimiento estándar para hacer un override de cualquier template que se encuentre dentro de un bundle de Symfony2.
Por supuesto, se pueden crear fácilmente plantillas de error específicas según el código de error. Para ello, simplemente debemos concatenar el código de error HTTP a la palabra «error» en el nombre del archivo, por ejemplo, podríamos montar una plantilla error404.html.twig específica para los errores 404 (Página no encontrada). El motor de Symfony utiliza el siguiente algoritmo para determinar qué plantilla utilizar:
- Primero, busca una plantilla del formato y código de error dado (por ejemplo, error404.json.twig) y si la encuentra, la sirve;
- Si no existe, se ignora el código de error y se busca la plantilla de error genérica para ese formato (en nuestro caso, error.json.twig);
- Si ésta tampoco existe, sirve la plantilla de error genérica de HTML (error.html.twig).
Lanzando un Error 404
Para lanzar un error 404 desde nuestra aplicación, tenemos la clase nativa de Symfony NotFoundHttpException:
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException; public function indexAction() { $producto = //recoger datos de BD if (!$producto) throw new NotFoundHttpException('Este producto no existe!'); //resto de la acción.. }
Es importante, a nivel de buena práctica de programación web, que cuando no se encuentra un elemento que el usuario ha solicitado se notifique al navegador mediante un error con código 404, aunque posteriormente sirvamos otro contenido alternativo (por ejemplo, una lista de posibles elementos relacionados).
Testeando el Error 500
Y para testear un Error 500 (el temido Internal Server Error), el código es tan simple como lanzar una excepción cualquiera desde nuestro controlador:
throw new \Exception( 'Error 500 de la Muerte!' );
Ojo, que no es un error tipográfico, debemos escribir \Exception, no Exception, porque si no PHP se irá a buscar \Namespace_de_tu_Controlador\Exception y nos vamos a encontrar con un Fatal Error: Class […] not found, en lugar de la excepción que queríamos.
Mientras programamos nuestro site en Symfony, tenemos que tener en cuenta que si estamos en entorno de desarrollo, las páginas de error que veremos no son las páginas de error de la versión de producción, sino las versiones debug para desarrollo, por ejemplo la plantilla sería exception.html.twig en vez de error.html.twig (por supuesto, éstas también pueden personalizarse, aunque son realmente majas). Si has perdido más de 20 minutos peleándote con la página de error por defecto y preguntándote porqué carajo no sale tu página personalizada, para después darte cuenta de que estabas viendo los debugs en entorno de desarrollo… no te preocupes, nos pasa a los mejores ;).
Por último, aunque ejemplos geniales e inspiradores de estas páginas de error user-friendly personalizadas los hay a puñados, aquí me gustaría destacar 2 sites que en mi opinión han hecho muy bien los deberes en este apartado: primero, GitHub por el uso innovador de una técnica de paralelaje en CSS para darle una pequeña interacción al usuario con esa sensación de profundidad, y a nivel nacional (y no es por pegarnos el pegote, es que realmente me encantan), nosotros mismos en Nosplay… todas ellas geniales, perfectamente integradas con la navegación normal del site y con un toque «adorablemente friki» con referencias a Star Wars :).
GitHub Página no encontrada: «Estas no son las páginas que estás buscando»
GitHub Error Interno de Servidor (te acabas de despeñar, chaval).
Nosplay Página no encontrada: «¡No puedes pasarrrr!»
Nosplay Error Interno de Servidor: «¡Soy tu padre!»
Y como bonus track, por si no habíais visto la página de error 404 de este humilde blog (¿no habéis puesto nunca «asdfasdf» detrás del /post/ en la barra de direcciones mientras visitáis nuestro blog? increíble!), como todavía no habíamos tenido excusa para mostrarla, aquí va una captura:
Aunque nosotros teníamos menos margen de maniobra al ser un WordPress y no un site construído en Symfony2 claro… ¿quizás para la próxima versión? 😉
Me ha venido como anillo al dedo para mi trabajo 😀
Me apunto tu web en favoritos, buen trabajo y una explicación perfecta.
gracias! lo necesito. Me lo llevo. Reitero mis felicitaciones por el excelente diseño de este blog! me gusto mucho!
Tu guia esta mucho mejor que la de symfony 😛
Pero tengo un problema, quiero hacerlo en el ambiente de producción, en el caso que haya algun error, pero siempre me da una página en blanco. Sabes cómo solucionarlo?
Jajaja gracias Oscar, compararnos con la guía de symfony es un pedazo de cumplido 😉
En principio, siguiendo los pasos descritos en este artículo no deberías de encontrarte nunca con una página totalmente en blanco. Como mínimo deberías toparte con las páginas de error por defecto que sirve el framework… La única diferencia entre entorno de producción y de desarrollo es lo que comento de que en entorno de desarrollo el framework nos servirá la versión debug, es decir exception.html.twig en vez de error.html.twig (por ejemplo).
Una pantalla en blanco suele ser señal de un fatal error de PHP que está siendo ocultado por la configuración de error_reporting del server. Habilita el error_reporting y mira a ver si es éste el problema. Según leo aquí: https://groups.google.com/forum/?fromgroups=#!topic/symfony-users/eB16WNtFBWg también problemas con los permisos de las carpetas del framework pueden provocar el toparte con páginas en blanco. Sin más detalles es difícil dar un diagnóstico más acertado, pero espero por lo menos haberte dado alguna pista!