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 Mon, 2008-10-06 at 18:08 -0300, Lucio Torre wrote:
> 2008/10/6 Daniel F Moisset <>:
> > 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:
> >
> [snip]
> > * 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")
>
> esto no se deriva de lo anterior. es decir, esto es por gusto tuyo.


Todo es por gusto mío, desde "mi esquema favorito es..." en adelante :)

La derivación de lo anterior viene por este lado: Yo propuse usar
excepciones sólo para casos donde no queda otro y estas seguro que estás
mal. Entonces, el contexto de una excepción (a lo que me refiero con "la
información ésta" en el párrafo que dejaste) puede ser realmente
cualquier cosa. Tenés una alteración de flujo de control por ser un
fallo (en base a la distinción binaria de "devuelve un valor"/"falla"),
pero cual fallo es probablemente no te importe mucho; de hecho puede ser
tan cualquier cosa que no hay mucho código útil que puedas escribir en
base a eso, así que adelante.

Si era una condición esperada y detectable, por que sería una excepción.

> yo diria que le cambiemos el nombre, en lugar de excepciones les
> podriamos poner, nose, condiciones. (gracias roberto).


Como quieras... en muchos lenguajes se le llama excepciones a cosas con
semántica un poco distinta. Le dije excepciones a esto porque no me
pareció fuera del rango, y de hecho es con el mismo propósito para el
cual dicen que son los sistemas de excepciones (léase
"fault-tolerance").

Ahora, para la gente que cree que las excepciones son "fancy flow
control" ó "goto 2.0", sí, capaz le va a resultar muy distinto lo que yo
propongo.

Lo que yo propongo no es un mecanismo muy distinto al de Python o Java
(es casi un subconjunto); es más una propuesta metodológica de _cómo y
cuándo usar_ las excepciones. No creo que eso amerite un nombre
distinto.

Para mi (y de vuelta, sí, esto es gusto personal), deberías poder
escribir cualquier sistema sin ningún exception handler, y si sos un
programador perfecto, tenés infinita RAM, tu hardware no falla, y no
pasan eventos externos raros, debería andar todo correcto; las
excepciones manejan los problemas de que no somos perfectos, la RAM es
finita, el hardware se rompe, y suceden eventos externos al programa y
fuera de control que influyen en su comportamiento. Pero en Python (o en
Java, para el caso), para escribir un programa cuya especificación sea
"mostrá el contenido de tal archivo, ó 'hola mundo' si no existe", estoy
forzado a poner exceptions handlers.

Para mi, que open() levante un IOError por no poder abrir un archivo, es
igual de incómodo/impráctico que si el operador < levantara una
excepción NotBigEnoughException al preguntar a<2 con a=3 [1]. Seguro que
igual podríamos programar todo (usando try/catch en casos que ahora
usamos if/else), pero lo siento como un abuso del mecanismo.

Saludos,
    D.


[1] Bueno, exagero un poquito en el ejemplo, pero creo que sólo porque
uso mas "<" que "open".



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