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

[DervishD]

    Hola Victor :)

 * Victor Moral <victor en taquiones.net> dixit:
> 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".

    No, si eso creo que está claro, pero también creo que si se pueden
combinar ambas cosas (excepciones y manejo tradicional) sería lo ideal,
y Perl eso lo permite. Otros lenguajes darían más problemas.

> > ¿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. 

    Ya, si en realidad la gestión mediante excepciones tiene muchas
ventajas y sólo un inconveniente, que es acostumbrar a los programadores
a usar este tipo de mecanismos.

    Eso sí, hay que valorar si para un script pequeñajo que te apañas en
un momento en tu sistema la gestión mediante excepciones es útil o es
matar moscas a cañonazos. Por eso digo que hacer convivir la gestión
tradicional no estaría mal.

> 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. 

    He estado ojeando el libro y probablemente me lo compre en cuanto
esté seguro de que mi mujer no me emasculará por comprar otro libro más
de chorradas de ordenadores XDDD

    En general, coincido bastante con la política de Conway de "ya sé
que jode, pero las cosas hay que hacerlas bien". Lo que no quiere decir
que esté de acuerdo con todo lo que dice en su libro, pero en lineas
generales pensamos parecido.
 
> 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.

    Pues que sepas que ya cuentas con un lector ;) Creo que los
programadores subestiman la importancia de una buena gestión de errores
y lo significativo que es al mantener el código y al reusarlo. Supongo
que es lo típico que la gente aprende por las malas...

> 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. 

    Bueno, lo del "isa()" se pasa un poco por el forro la encapsulación
y no es buena práctica para un diseño orientado a objetos, en mi
opinión, pero entiendo el mecanismo y personalmente también usaría isa()
para gestionar, en lugar de hacer un framework que obligase al llamante
a usar una implementación y diseños orientados a objeto. Es un buen
compromiso usar "isa()".

> NO están escritas en Perl, obviamente, sino usaríamos algo más
> "moderno" e infernal como el XML. ;-)

    No, de verdad, olvida XML XDDDDD Sólo "expat" lo hace digerible, y
poco, la verdad XD

> > 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. 

    Nunca he usado Exception::Class, pero le echaré un ojo. Soy bastante
reacio a usar módulos que no vengan en el core, así que (como soy un
capullo y lo sé y no me importa) igual me escribo algo similar para
colocarlo en mi Common.pm. Me gusta la abstracción de usar "throw" en
lugar de "die", que me parece mucho más intuitivo aunque sea sólo un
cambio de nombre. Y sí, ciertamente facilita la gestión de excepciones.

>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. 

    Estoy acostumbrado a no usar depuradores paso a paso, suelo usar
otras técnicas y sólo recurro al debugger cuando no puedo evitarlo.
Además, se supone que gestionando los errores así deberías ahorrarte
bugs...

    Supongo que ningún código del que maneja excepciones de tu trabajo
está bajo licencia GPL o similar ¿me equivoco? Es que estaría muy bien
ver la propagación de excepciones en acción.

    Por cierto que hace un tiempo escribí un código de prueba para hacer
excepciones en C, usando setjmp y longjmp, pero lo dejé porque aunque
funcionaba, había demasiados cabos sueltos, y es que intentar añadir
semántica try/throw/catch al C es una locura. Al final lo hice a la
forma C, con una librería de gestión de excepciones... que nunca terminé
(¿he hablado ya del vicio que tengo de procastinar?, pues eso).

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!