[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