Open GoogleCodeExporter opened 9 years ago
Estoy de acuerdo en devolver un none o en su defecto un código de error que
puede ser interpretado por la función error, aunque el código de error puede
tender a confundirse con el resultado de la función en funciones como det(M).
Original comment by diegolo...@gmail.com
on 27 Feb 2013 at 5:09
Otro punto a favor de no disparar errores es que no me gusta que pase :)
Es decir, alguna vez me ha pasado que he hecho algún script en python y ha
saltado un error dentro de algún módulo que he utilizado. Y no me ha gustado
nada, por sentirme como que tenía que revisar el código de ese módulo para
ver que pasaba. Nunca lo he hecho.
Si el error salta en el código que yo he escrito, es otro cantar. Porque sé
qué es lo que está haciendo (o debería saberlo) y no me da miedo revisarlo.
Original comment by felipe.hommen
on 1 Mar 2013 at 6:54
En algunas funciones como en la de comprueba(M) se debería imprimir una cadena
de texto con el error en caso de que devuelva false.
ej
print error(2)
Fallo de formato, compruebe si es correcta la escritura de la matriz
Así si alguien usa el modulo desde el terminal y escribe mal una matriz se
dará cuenta. Sobre todo si usa una función que llame a comprueba(M), ya que
leerá el mensaje en vez de ver que no ha pasado nada por que la función ha
reconocido que no es una matriz valida.
Original comment by diegolo...@gmail.com
on 14 Apr 2013 at 4:16
Pues me parece la mejor manera de gestionarlo. De hecho ahora me parece la
manera obvia ¡Pues claro!
Un matiz que aportar: supongo que la manera más "siguiendo el protocolo" de
hacerlo sería sacar los errores por la salida de error estándar, es decir,
>> sys.stderr.write(error(2))
en vez de
>> print(error(2))
Por lo que a mí respecta, empiezo a aplicar esta manera de gestionar los
errores inmediatamente.
¡Pues claro!
Original comment by felipe.hommen
on 14 Apr 2013 at 4:30
Original issue reported on code.google.com by
felipe.hommen
on 26 Feb 2013 at 9:21