Post by Gabriel GenellinaEn Fri, 03 Oct 2008 19:17:56 -0300, Mariano Guerra
Post by Mariano GuerraPost by Gabriel GenellinaEn Fri, 03 Oct 2008 16:34:18 -0300, Juan B Cabral
En Python la regla sería, parafraseando a mi abuela: "Si no tenes nada bueno
que hacer con la excepcion, sencillamente no la atrapes". Que siga su curso,
hasta que alguien más arriba con mas "contexto" la atrape y haga algo útil.
quería agregar algo a la discusión, si bien es insoportable que el
lenguaje te obligue a tratar excepciones en todos lados o a reportar
explícitamente que no la vas a tratar, esta bueno que el lenguaje sea
capaz de averiguar y decirte cuales excepciones tira un método.
Por ejemplo, en C# no te reta si no tratas una excepción y no tenes
que declarar que la tiras, pero tampoco te dice cuales son las que
tira, lo que lleva a buscar las excepciones que tira en la
documentacion y el 99% del tiempo nadie escribe que excepciones puede
tirar por la simple razón de que documentar es un perno y que de
arranque no sabes que excepciones tiran los métodos que usas vos.
A que voy con esto? me encantaría que python siga como es, pero que
si me interesa, me diga que excepciones pueden llegar a saltar, de esa
manera si realmente quiero hacer un try/except, puedo tratar las
excepciones de una forma "granular" y no hacer un except Exception
porque no se que puede saltar o ir agregando clausulas a medida que
saltan. :)
el que escribio el texto al que estas respondiendo soy yo, no el
creador del thread ni del programa. :D
Post by Gabriel GenellinaCreo que estas enfocando el problema al reves. En general, no hace falta que
atrapes las excepciones que no conoces. Si vas a atrapar una excepcion es
porque queres hacer algo especifico con ella - si no tenes nada bueno para
hacer, no la atrapes y punto.
Es que yo si las quiero atrapar y no se cuales son :D, para dejar mas
claro esto, te posteo un fragmento de un post que escribi en mi blog
hace mucho (estaba un poco enojado cuando lo escribi pero se rescata
el mensaje :P)
[Quote]si tenes una retorcida adicción a lanzar excepciones haceme el
favor de atraparlas, y si la vas a atrapar hace algo útil, no vale
atraparla y no hacer nada[/Qoute]
a lo que referia con retorcida adiccion es que alguien me metio un
raise cada 5 lineas de codigo en un modulo cada vez que algo no le
gustaba (digamos que en vez de hacer un if para ver si habia una
llave, tiraba una excepcion :P)
Post by Gabriel GenellinaSi pensas que sí hace falta atraparla, es porque posiblemente estas pensando
en un modelo de ejecución donde los errores se propagan a traves de un
codigo de retorno (típicamente: 0=OK, 1=paso tal cosa, 2=paso tal otra...).
Exactamente, soy partidario de lanzar excepciones en casos en los que
no puedo hacer nada para solucionar un problema (no tengo la
informacion necesaria, no es el lugar o requiero que alguien en el
stack de llamadas se entere), pero tambien soy partidario de atrapar
excepciones en el punto que corresponde haciendo lo necesario para
solucionar el problema, para evitar que la excepcion para arriba y me
termine haciendo funcionar mal el programa.
Post by Gabriel GenellinaEn un modelo basado en excepciones, esto no es asi: si sucede algun
problema, lo comunicas a traves de una excepcion, no de un codigo de
retorno. Y dejas que la excepcion siga su curso hasta que "alguien" la
atrape porque tiene algo "util" que hacer con ella.
totalmente de acuerdo, el valor de retorno de una funcion lo veo como
el resultado de una funcion matematica, es el resultado de la
ejecucion de la funcion, no un medio para comunicar otras cosas..
Post by Gabriel GenellinaPor ejemplo, tu funcion set_whyname_file ahora devuelve un *texto* de error.
no es mia :D
Post by Gabriel GenellinaVos sentis la "necesidad" de atrapar todas las excepciones posibles, para
poder devolver un texto válido en cada caso. Si esa funcion simplemente
lanzara una excepcion cuando hay un problema (bien sea el IOError original,
o cualquier otra cosa), entonces no tendrias la "necesidad" de atrapar nada.
no es mio :D, y para aclarar, no siento la necesidad de atrapar todas
las excepciones, solo tengo la necesidad de saber cuales son las
posibles excepciones que pueden saltar asi decido cuales tratar, me ha
pasado que despues de que un programa mio esta siendo usado por 6
meses me llega un bug report de una excepcion que salta en una parte y
agrego el try/except en el lugar adecuado, y a los 2 meses me llega
otro bug report con otra excepcion muy rara que salta en el mismo
lugar. Me gustaria saber cuando agrego los except cuales son las
excepciones que pueden saltar en ese lugar para tratar las que
considere "tratables" en ese punto. Ese era el punto de mi mail
anterior.
Post by Gabriel GenellinaEn un lenguaje con buen soporte de excepciones como es Python (o C++ para
mencionar algun otro), ésa es la mejor forma. En otros lenguajes (como C por
ejemplo) no te queda otra que pasarte la vida chequeando codigos de retorno
una y otra vez, en todas y cada una de las funciones que llamas. Te
olvidaste de hacerlo en algun lado (porque se te paso, por ignorancia,
porque estabas cansado, porque pensaste "esto no puede fallar nunca"...) y
ya tu programa hace cualquier verdura y es dificil darse cuenta qué pasó...
totalmente de acuerdo (alguien chequea la salida de printf en C para
saber si se escribieron todos los caracteres? :D)
Post by Gabriel GenellinaClaro que hay situaciones donde realmente convendría saber cuáles
excepciones podrían suceder, pero en general es algo imposible de determinar
a priori.
Por esto me voy a tener que aguantar el odio de muchos, pero java lo
hace (o casi lo hace), no digo que sea perfecto, pero un metodo es un
arbol de llamadas a otros metodos, la forma mas simple seria recorrer
los metodos llamados y ver los raise (no es 100% efectivo, pero al
menos me da un hint de que puedo llegar a esperarme).
Post by Gabriel GenellinaCualquier funcion puede disparar cualquier excepcion, y no hay
forma de predecirlo. open(filename) *usualmente* falla con IOError, pero si
filename no es una string va a saltar un TypeError, y siempre podria haber
un MemoryError, y si el nombre "open" apunta a otro objeto que no es la
funcion predefinida "open" (como en la version anterior de tu programa, que
redefinia string y list como variables), el resultado puede ser
absolutamente cualquier cosa. Python es dinámico también en este aspecto,
asi que anda acostumbrándote...
Estoy de acuerdo, a fin de clarificar digamos que hay tres tipos de
errores, los errores de operaciones (del tipo "no podes abrir ese
archivo" o "el archivo no existe"), las excepciones inherentes a un
lenguaje dinamico (del tipo "lo que pasaste es un tipo invalido", "no
existe el metodo x para la variable y" etc) y las excepciones
totalmente raras (del tipo "te quedaste sin memoria", "no se puede
escribir en standar output", o excepciones del interprete). A mi me
interesaria saber las excepciones operacionales o "resultantes de la
ejecucion valida del metodo pero que por razones diversas como la
combinacion de valores de las variables genera un estado de
excepcion".
Post by Gabriel GenellinaEstoy seguro de que con el tiempo se te van a pasar :)
y si, me tengo que acostumbrar, pero me parece interesante discutir
las cosas buenas de otros lenguajes o cosas que nos gustaria ver en
nuestro lenguaje preferido.
Perdon por el post largo...
PD: para que quede mas claro (o menos ;) aca va un ejemplo, este es un
proyecto mio, primero vemos la cantidad de lineas:
$ wc -l *.py
<snip>
19096 total
ahora vemos la cantidad de excepts que use:
$ grep except *.py | wc -l
129
veran que no soy un fanatico de atrapar excepciones por deporte, pero
tampoco que me gusta que mi app se le cierre a alguien por una
excepcion que ni siquiera sabia que podia saltar en cierto punto
(vease mas arriba el tipo de excepciones de las que quiero saber)