[Ambar-dev] Enfoque más sistemático del tratamiento de errores

[Andres Moya]

Buenas.

Ya tengo el Linux bien en el trabajo, y también he encontrado ratos para 
trastear con el Mine ...  (guay)  Lo que no tengo es CVS, porque tengo un 
firewall gordo que no me deja pasar. Pero bueno, no es grave, me lo mando por 
mail a mi casa y hago el update desde aquí.

Estoy pensando que hay que meter un poco más de "ingeniería del software" 
para conseguir que el programa sea más robusto sin meter demasiados pegotes. 
Voy a repasar todo el programa añadiendo una técnica que se llama "diseño por 
contrato" (algún día te lo explicaré), que a grosso modo significa que hay 
que añadir en todas las clases y todas las funciones unas "aserciones", que 
son como las cláusulas del contrato que la clase/funcion se compromete a 
cumplir. En realidad es un poco más largo, pero así se consigue prevenir y 
detectar mejor los errores. Lo malo es que el Python no incorpora esto en el 
lenguaje, así que me tengo que inventar una manera de hacerlo...

He empezado por el fichero sala.py. Hay tres tipos de aserciones:

- Invariantes: pertenecen a una clase. Son condiciones que se tienen que 
cumplir siempre. Por ejemplo, en la clase Sala, la invariante "id != None" 
significa que desde fuera siempre es seguro escribir unasala.id (no hace 
falta chequear if unasala.id != None). O la invariante "personajes[i].sala == 
self" significa que la lista "personajes" contiene sólo personajes cuya sala 
es la actual. Todos los métodos de la clase tienen que asegurarse de que 
ninguna invariante esté rota antes de hacer return. 

- Precondiciones: son condiciones que deben cumplirse antes de llamar a una 
función, y es responsabilidad del llamante asegurarse de que se cumplen (se 
etiquetan con la palabra "requiere"). Por ejemplo, salir_personaje tiene la 
precondición "personaje in self.personajes.values()", que significa que sólo 
puede salir un personaje que ya esté en la sala.

- Postcondiciones: son condiciones que la función se compromete a cumplir 
cuando termine. Por ejemplo, salir_personaje "asegura" que "personaje not in 
self.personajes.values()". O sea, cuando termine la función el personaje ya 
no está en la sala.

Hay un lenguaje (Eiffel) - que, por cierto, también me gusta bastante - que 
incorpora esto en el propio lenguaje y tiene opciones para comprobarlo 
automáticamente. En Python por el momento, lo pondremos en los comentarios y 
lo comprobaremos a mano.

Cuando las aserciones están colocadas, el tratamiento de excepciones y 
errores se puede hacer de una manera bastante sistemática, pero eso ya te lo 
explicaré otro día :)