Re: [pyar] Re: whyname corregido

Top Page
Attachments:
+ (text/plain)
Delete this message
Reply to this message
Author: Daniel F Moisset
Date:  
To: pyar
Subject: Re: [pyar] Re: whyname corregido
On Fri, 2008-10-03 at 19:17 -0300, Mariano Guerra wrote:
> 2008/10/3 Gabriel Genellina <>:
> > En Fri, 03 Oct 2008 16:34:18 -0300, Juan B Cabral <>
> > escribió:
> >
> > Java tiene excepciones chequeadas (una metida de pata de diseño) y entonces
> > es re comun que haya que atrapar todas las excepciones que aparecen nada mas
> > para cambiarles el tipo. Eso para lo unico que sirve es para esconder
> > informacion valiosa (como cuál fue el verdadero error original), o induce a
> > que los programadores escriban [el equivalente a] esto:
> >    try: ...
> >    except: pass
> > que es como esconder el polvo abajo de la alfombra.

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


Son approaches distintos a manejo de excepciones...

Mi favorita es la versión espartana/minimalista, basada en "una rutina
tiene que hacer una sola cosa y hacerla bien". Eso, llevado a diseño de
un sistema de excepciones queda en:

* Una rutina tiene dos finales posibles: devuelve un valor, o falla
* Estos "fallos" no son objetos (del mismo modo que "dar la última
vuelta en un while" o "entrar por la rama else de este condicional" no
son objetos). Puede haber un objeto con algo de contexto del fallo
generado por el runtime, pero esto es algo más a nivel
runtime/biblioteca que a nivel lenguaje.
* La información esta es para debugging más que para control: Un fallo
quiere decir que se produjo una situación inesperada y muy desconocida.
Para manejar situaciones inusuales pero que son "esperadas" o
"conocidas" se usa el flujo de control usual (léase "if")
* Los fallos se manejan a nivel rutina, no a nivel bloque
* Una rutina puede manejar un fallo de dos formas posibles: propagar el
fallo (posiblemente haciendo cleanup), o recomponer el estado inicial y
reintentar.

Usar esto elimina la pregunta de Mariano "¿Que excepciones puede tirar
esta rutina?" y la preocupación por la Javitis de "tengo que manejar
_tooodas_ las excepciones", además de ser coherente con lo que dice
Gabriel de "cualquier funcion puede disparar cualquier excepcion,
y no hay forma de predecirlo [ejemplo de open()]".

La pena es que en Python es muy difícil, dado que para que sea efectivo
requiere que la cultura (y en particular, la biblioteca estándar) sea
más o menos coherente con esta idea, en vez de levantar excepciones por
boludeces como "hiciste open() a un archivo inexistente".

Saludos,
    D.




---------------------------------------------------------------------
Para dar de baja la suscripcion, mande un mensaje a:


Para obtener el resto de direcciones-comando, mande un mensaje a:


PyAr - Python Argentina - Sitio web: http://www.python.com.ar/