[Madrid-pm] [RFC] Gestión de errores

Victor Moral victor en taquiones.net
Vie Mar 16 02:48:20 PDT 2007


El Viernes, 16 de Marzo de 2007 10:05, DervishD escribió:

>     Hasta ahora en las cosas que he hecho tanto en C como en Perl y
> otros lenguajes, he adoptado la postura de notificar los errores en un
> valor de retorno, bien sea de una función, bien sea de un método de una
> clase, aparte de otros mecanismos. Esto lo he hecho así porque
> principalmente escribo bibliotecas y no programas como tales, y los
> usuarios son vagos y las excepciones iban a cabrearles...

	Tal vez, pero si creas tú las herramientas tú pones las reglas de cómo se 
usan. Y ejemplos de bibliotecas asquerosas de usar aunque muy eficientes hay 
bastantes. Lo peor que puede pasar es que hagan un "fork".

>     ¿Qué opinais al respecto?

	Tras unos meses de uso de un sistema de errores mediante excepciones, en 
producción, mi opinión es que es muy recomendable. 

	Siguiendo los consejos (por llamarlos de alguna manera, se parecen más a 
órdenes tajantes :-) ) de Damian Conway empecé a probar con Exception::Class 
en nuestras librerías y ya no concibo otra forma de encarar el tratamiento de 
errores para una aplicación. 

	Aún estoy trabajando en una página sobre ello, hablando sobre la experiencia 
y demás, pero en realidad lo que hay que cambiar un poco es la forma de 
encarar estos errores.

	Se parte de una jerarquía de clases que definen y agrupan los errores por 
categorías, de tal manera que podemos saber (con un simple isa()) qué error 
es y/ó a qué categoría pertenece. 

	En el resto del código llamamos a la función, método ó subrutina 
correspondiente protegida por un eval y recogemos su valor sin más. La 
diferencia es que a continuación comprobamos si se ha producido la excepción 
y, en caso afirmativo, si PODEMOS encargarnos de ella. En caso contrario la 
relanzamos hacia atrás sin modificar sus datos.

	En nuestro caso la estamos utilizando en un programa de generación de 
impresos que hemos construído nosotros. Aplicaciones antiguas se limitan a 
abrir una conexión de red, a enviarle un encabezado indicándole el listado 
que va a usar y un chorro de datos en un formato simple. Esas aplicaciones 
antiguas NO están escritas en Perl, obviamente, sino usaríamos algo 
más "moderno" e infernal como el XML. ;-)

	Pues bien, en cada uno de las fases de proceso tenemos un sistema común de 
excepciones. Si el error producido, por ejemplo, es un campo con un valor 
erróneo podemos descartar la línea sin más problemas, pero si se corta la 
conexión de red ó se acaba el espacio en disco, la mayor parte del código 
relanzará la excepción hacia atrás hasta la parte del servidor, que algo hará 
con ella, porque NO saben qué hacer con un error de ese tipo.

>     Mi opinión es que me encantaría poder combinar ambas cosas, y hasta
> cierto punto se puede hacer, usando "wantarray" y lanzando excepciones
> siempre que la función se esté llamando en "void context", pero si uso
> excepciones (en realidad mi preferida) prefiero usar siempre referencias
> para poder estructurar la información que devuelve el error. Lo que no
> tengo claro es si usaría una clase para ello o una simple referéncia
> anónima a un hash.

	Sí, claro, además con Exception::Class y similares puedes definir mucha 
información extra en las excepciones y producir bonitos y útiles mensajes de 
error. 

	Hay un aspecto que también es necesario tener en cuenta y es la depuración 
paso a paso; con el depurador gráfico de Perl, pdbtk, es difícil trazar la 
ejecución de un programa con múltiples eval. Y olvídate de poner puntos de 
ruptura como haces con un programa normal, se niega a recordar nada de eso en 
la configuración de la sesión. Sé que existe otro depurador ebug en CPAN, 
bastante bien estructurado, pero no he llegado a probarlo porque instalarlo 
en Debian era un infierno. 

Saludos
-- 
 --------
 Víctor Moral <victor en taquiones.net>
 http://www.taquiones.net/victor.html
 Usuario Linux nº 139246
 Clave pública 0x376B5EA7 en pgp.rediris.es

------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 189 bytes
Descripción: no disponible
Url        : http://mail.pm.org/pipermail/madrid-pm/attachments/20070316/7975f2d7/attachment.bin 


Más información sobre la lista de distribución Madrid-pm