Control de Errores en las JSP

Depuraci�n de errores en JSPs.

Fecha de creaci�n: 05.08.2003

Revisi�n 1.0 (05.08.2003)

Eneko Gonz�lez Benito
enekog AT euskalnet DOT net

Copyright (c) 2003, Eneko Gonz�lez Benito. Este documento puede ser distribuido solo bajo los t�rminos y condiciones de la licencia de Documentaci�n de javaHispano v1.0 o posterior (la �ltima versi�n se encuentra en /licencias/).

Introducci�n

Todos, tarde o temprano, cometemos errores en nuestra programaci�n, que derivan en excepciones que son lanzadas en tiempo de ejecuci�n. En el caso de las p�ginas Java de servidor (JSP), existe una forma bastante simple, potente y a la vez elegante, de depurar dichas excepciones.

Para ello, vamos a hacer uso de dos directivas de p�gina, errorPage e isErrorPage, que vamos a explicar a continuaci�n.

Lanzando la excepci�n.

Para poder tratar la excepci�n lanzada en un fichero JSP, necesitamos indicar en dicho JSP la URL del fichero que va a realizar el tratamiento de dicha excepci�n.
Para ello, utilizaremos la directiva errorPage. Por ejemplo, el siguiente c�digo indica que la excepci�n ser� tratada en el fichero /error.html

<%@ page errorPage = "error.html">

Antes de continuar, vamos a explicar para que sirve esa l�nea. Supongamos que tenemos un JSP llamado index.jsp[1] que contiene, entre otras, las siguientes l�neas:

<%@ page errorPage = "error.html"%>
...
El n�mero recibido es <%=Integer.parseInt(request.getParameter("numero"))%>.
...

Supongamos, adem�s, que el contenido del fichero error.html es el siguiente:

<BR> Algo ha fallado <BR>

En el caso de que se produzca una excepci�n en el c�digo del fichero index.jsp, el servidor redirigir� la petici�n al fichero error.html en el punto en que haya ocurrido la excepci�n. Esto es, si la excepci�n ha ocurrido en la instruccion Integer.parseInt(), el resultado de la petici�n, que al fin y al cabo es lo que ve el usuario, ser� el siguiente:

El n�mero recibido es <BR> Algo ha fallado <BR>

En el siguiente gr�fico podemos ver f�cilmente el flujo que ha seguido el servidor para generar la respuesta.

Recogiendo la excepci�n.

Lo que hemos visto hasta ahora, no es demasiado �til, ya que solo podemos mostrar un mensaje diciendo que ha habido un error, pero poco mas. Sin embargo, �que ocurre si, en vez de lanzar las excepciones al fichero error.html, lo hacemos al fichero error.jsp[2]? El resultado es el mismo, salvo que el fichero error.jsp va a ser ejecutado como cualquier otro JSP, lo que nos da la posibilidad de hacer m�s cosas.

Para poder recoger la excepci�n, el fichero error.jsp debe incluir la directiva siguiente:

<%@ page isErrorPage = "true"%>

Ahora ya podemos recoger la excepci�n desde nuestro nuevo fichero, y mostrarla por pantalla. Para eso, el fichero JSP tiene instanciado un objeto llamado exception, de la clase java.lang.Exception, que contiene dicha excepci�n. As� pues, mostrarla por pantalla es tan f�cil como incluir en el fichero error.jsp el siguiente c�digo:

<%@ page isErrorPage = "true"%>

<% if (exception != null) { %>
La excepci�n causante del error ha sido:
<% exception.printStackTrace(new java.io.PrintWriter(out)); %>
<% } // del if%>

Rizando el rizo.

Ahora ya sabemos, de una manera f�cil, la forma de conocer la excepci�n que ha ocurrido en nuestro programa. A continuaci�n, vamos a ver como, a�adiendo un poco m�s de c�digo a nuestro JSP, podemos mostrar gran cantidad de informaci�n �til para depurar la causa de la excepci�n.

• 
  

  Atributos del objeto Request: El objeto request contiene gran cantidad de informaci�n sobre la petici�n que se ha hecho al servidor, como el m�todo usado (get/post), la IP del cliente, etc. Afortunadamente, el objeto request tiene un m�todo llamado getAttributeNames() que devuelve un objeto de la clase java.util.Enumeration con el nombre de todos los atributos del objeto. As�, para obtener toda la informaci�n de dicho objeto, podemos utilizar el siguiente c�digo:
  

  <%
  java.util.Enumeration enum;
  String atributo;
  
  enum = request.getAttributeNames(); // Leemos todos los atributos del request
  
  while (enum.hasMoreElements()) {
  
  atributo = (String) enum.nextElement();
  %>
  <%=atributo%> = <%=request.getAttribute(atributo)%> <BR>
  <%
  } // del while
  %>

  
  

• Par�metros: Adem�s de los atributos anteriores, es muy interesante saber qu� par�metros ha recibido el JSP a trav�s del objeto request. La manera m�s sencilla de mostrarlos todos es muy similar a la anterior:
  

  <%
  java.util.Enumeration enum;
  String parametro;
  
  enum = request.getParameterNames(); // Leemos todos los par�metros recibidos
  
  while (enum.hasMoreElements()) {
  
  parametro = (String) enum.nextElement();
  %>
  <%=parametro%> = <%=request.getParameter(parametro)%> <BR>
  <%
  } // del while
  %>

  
  

• Objetos de sesi�n: Objetos de sesi�n: Por �ltimo, aunque no menos importante, suele ser interesante conocer el contenido de la sesi�n. Para ello, utilizamos un c�digo muy similar a los anteriores, aunque con alguna peque�a diferencia:
  

  <%
  java.util.Enumeration enum;
  String elemento;
  
  session = request.getSession(true); // Creamos la sesi�n, si no existe
  %>
  
  Sesi�n activa desde: <%=new java.util.Date(session.getCreationTime())%%> <BR>
  Ultimo acceso: <%=new java.util.Date(session.getLastAccessedTime())%> <BR>
  Contenido: <BR><BR>
  
  <%
  enum = session.getAttributeNames(); // Leemos todos los objetos de sesion
  
  while (enum.hasMoreElements()) {
  
  elemento = (String) enum.nextElement();
  %>
  <%=elemento%> = <%=session.getAttribute(elemento)%> <BR>
  <%
  } // del while
  %>

  
  

Pensando a lo grande.

Hasta ahora, hemos visto una manera de tratar las excepciones en un fichero JSP concreto, mediante la directiva errorPage. Imaginemos que, como suele ocurrir, tenemos una aplicaci�n formada por 50 ficheros JSPs. Si queremos tratar las excepciones de los 50 JSPs, tenemos dos posibilidades:

• Incluir la directiva errorPage en todos y cada uno de los JSPs. Esto supone que hay que modificar los 50 ficheros, lo que puede costarnos bastante tiempo, a parte de que es muy f�cil que nos dejemos alguno sin modificar y luego nos cueste much�simo tiempo encontrarlo.

• Buscar un lugar donde podamos indicar al servidor de aplicaciones que todos los JSPs en los que ocurra una excepci�n, sean tratados de la misma manera. Esta opci�n, que seguro que a todos nos parece m�s inteligente (a no ser que un JSP concreto requiera un tratamiento de errores diferente al resto, cosa que no suele ocurrir), nos obliga a hacer una peque�a modificaci�n en el fichero web.xml de nuestra aplicaci�n, a�adiendo las siguientes lineas:
  

  <error-page>
  <exception-type>java.lang.Exception</exception-type>
  <location>/error.jsp</location>
  </error-page>

  
  

  Su funcionamiento es bastante sencillo. Simplemente le estamos diciendo al servidor que, cuando ocurra una excepci�n de la clase java.lang.Exception, o de una clase que herede de esta, redirija la petici�n al fichero error.jsp de la misma manera que lo hac�a con la directiva errorPage.

  
  

Una �ltima vuelta de tuerca.

Ya sabemos como mostrar la informaci�n de las excepciones ocurridas en los JSPs, para tratar de agilizar su depuraci�n. Ahora bien, si nuestra aplicaci�n est� siendo utilizada por clientes, es muy posible que no nos interese que el cliente pueda ver toda esa informaci�n, y que esta solo sea visible para los desarrolladores.

Existen varias maneras de hacer que el cliente no vea todos esos datos, sino que simplemente vea un mensaje pidi�ndole disculpas. Recordemos que la excepci�n va a ser tratada en un fichero JSP, luego podemos mostrar la informaci�n importante solo en los casos que queramos. Por poner un ejemplo sencillo, pero a la vez �til, podemos detectar la IP del cliente con el m�todo request.getRemoteAddr(), y si la IP pertenece a un desarrollador de nuestra empresa, mostramos todos los datos, y si no, mostramos solo el mensaje disculp�ndonos. Evidentemente, hay m�s formas de hacer esta discriminaci�n entre desarrolladores y clientes, y cada uno puede utilizar la que mejor se adapte a sus necesidades.

Conclusi�n

Ya hemos visto una manera bastante sencilla de depurar las excepciones de nuestros JSPs. La intenci�n de este art�culo es mostrar de una manera sencilla las posibilidades que nos ofrecen los JSPs para depurar errores, pero por si alguien cree que con esto aun no es suficiente, aqu� van un par de ideas para desarrollar:

• 
  

  
  �Qu� ocurre con los errores ocurridos en los servlets? Podemos aprovechar el JSP que hemos construido para ver tambi�n dichos errores. Lo �nico que hay que hacer es, cuando salte una excepci�n en un servlet, redirigir la petici�n al fichero error.jsp.
  

  
  
• 
  

  
  �Podemos conocer mas datos de, por ejemplo, los objetos que est�n en sesi�n? Claro que es posible, y posiblemente ser�a muy util, pero queda fuera del alcance de este art�culo. Utilizando el paquete java.lang.reflect, podemos obtener los valores de todas las propiedades p�blicas de los objetos que est�n en sesi�n y mostrarlos por pantalla. No solo eso, sino que tambi�n podemos obtener todos los m�todos de esos objetos, ejecutarlos, y mostrar el resultado por pantalla. Si esos m�todos son los accesores (getters) de las propiedades del objeto, podemos conocer todos los datos de un objeto. Al final, con un poco de paciencia, y utilizando la recursividad, podemos convertir nuestro JSP para el tratamiento de errores, en un inspector de objetos.
  

  
  

Recursos

[1]
Ejemplo de fichero que genera una excepci�n (nuestro index.jsp).

[2]
El JSP utilizado para tratar las excepciones (nuestro error.jsp).

Acerca del autor

Eneko Gonz�lez Benito
Eneko lleva varios a�os programando en Java, y actualmente trabaja como programador Java en una peque�a consultor�a en Bilbao.
El poco tiempo libre que le deja el trabajo, se dedica a practicar deportes (senderismo, futbol, frontenis entre otros) y a leer todo lo que pasa por sus manos.