Feedback AC06

[Drpinto1]

Feedback AC06:

Resumen:

A continuación se encuentran los errores más comunes de la actividad AC06, si bien muchos ya conocían el funcionamiento básico de try/except, es importante que comprendan cómo utilizar correctamente esta herramienta. general para actividades y tareas, deténganse a leer bien los tips que entrega el enunciado y reconozcan bien cuando es necesario o no levantar y/o atrapar una excepción.

Como siempre, si tienen alguna duda respecto a cualquier cosa expuesta aquí, ¡No duden en preguntarla en esta o en una nueva issue! 😄

Errores generales

• Deben saber que except Exception es una muy mala práctica. Siempre deben especificar el error cuando este sea capturado, para así tener el control sobre lo que está pasando en el programa. Al poner except Exception (lo que es equivalente a un except: sin especificar nada), estamos capturamos cualquier error que ocurra dentro del try sin saber su naturaleza, lo cual puede causar comportamiento inesperado en el programa y no es bueno para nosotros (los programadores) al momento de debuggear o detectar problemas. El usar esta sentencia pone en evidencia que no se sabe cual es el error tratado, y no lo resuelve o maneja realmente.

• Parte del aprendizaje para esta semana era que luego de una sentencia try, deben escribir un except para cada excepción diferente que pueda ocurrir dentro del try, ya que así se puede controlar el flujo del programa según cada error. No es útil poner todas las excepciones en el mismo except, ya que todos los errores seguirán el mismo flujo y el resultado será similar a hacer except Exception, a menos de que corresponda manejarlos de la misma forma.

• Cuando quieren revisar si una estructura de datos está o no vacía, recuerden que en lugar de hacer if struct == [] o if len(struct) == 0, pueden hacer simplemente if struct. Lo anterior es válido para diccionarios, listas, tuplas, sets y en general para la mayoría de las estructuras de datos.

• Similar a lo anterior, cuando quieren revisar si una expresión booleana cumple o no cierta condición, en lugar de hacer if expr == True o if expr == False, es posible ahorrar código, escribiendo if expr y if not expr.

• Tengan cuidado con qué tipo de excepción levantan para cada error que se produce en el código, pues tiene esta que ser descriptiva del error. Por ejemplo, el no encontrar una llave en una estructura que funciona similar a un diccionario, deberían levantar un KeyError, en lugar de un ValueError.

• Recuerden que cuando queremos que pase algo sólo si no se levantaron excepciones, se debe utilizar la sentencia else luego del try/except, pues una línea que se encuentra al mismo nivel de indentación que try/except pero luego de ellos en el código, se ejecutará sin importar si ocurrió o no un error.

• Si bien los nombres de las excepciones ya son bastante descriptivos del error que representan, la idea de la actividad, y de los contenidos de la semana, es que puedan detallar la excepción utilizando mensajes personalizados al levantarla. Lo ideal era pasar mensajes distintos según la falla encontrada (aunque haya sido el mismo tipo de error) de la forma raise ValueError(‘Mensaje descriptivo del error’).

• Al momento de llamar a una función que obtiene datos de un archivo, ya implementada, que recibe como parámetro un path, no se debe abrir el archivo antes de llamarla, pues la función se encarga de abrir, leer y cerrar el archivo.

Errores específicos de la actividad:

• Al crear la excepción personalizada, muchos hicieron que esta imprima un mensaje basado en un parámetro que se recibe al inicio (de la forma ErrorPatente(patente)) y con el atributo self.mensaje = f“ La patente {patente} no se encuentra en el registro”. La definición anterior es correcta, sin embargo muchos cometieron un error al levantar la excepción; la manera correcta sería raise ErrorPatente(“alguna_patente”), lo que luego imprimiría “La patente alguna_patente no se encuentra en el registro”.

• Muchos confundieron ValueError con TypeError, levantando el error incorrecto en distintas ocasiones; TypeError tiene relación con el tipo del dato, mientras que ValueError tiene que ver con el contenido de los datos. En caso de la actividad, si se está revisando un RUT de la forma ”ABC19638-0”, podría parecer un TypeError, pues el RUT contiene letras, que no son caracteres numéricos. Sin embargo, la variable completa es del tipo correcto, str, por lo que una excepción más adecuada sería ValueError, pues la variable contiene valores que no son apropiados.

Nuevamente les recordamos, cualquier duda que tengan, pueden preguntarla en esta o en una nueva issue 😄