Cita:
|
Empezado por dec
¿Puedes indicar algunas de ellas por ver si de una vez por todas puedo entenderlas? Estoy seguro de que son muchas las obviedades que se me escapan, pero no me parece mal que me las hagan saber.
|
Un par de ejemplos:
Problema: El usuario no puede entrar al sistema, le dice que los datos son incorrectos; su hijo-
que sabe computación -dice que el sistema está mal hecho.
Razón: en el recuadro que dice:
Escriba se fecha de nacimiento (dd-mm-aaaa)
el usuario escribe 1983/05/31
(¿Qué no es obvio? ¡Le estoy indicando el formato de la fecha!)
Conclusión: (desafortunadamente) el hijo tiene razón
Solución: antes de mandar los datos al servidor, verificar el formato y mandar un mensaje pertinente en caso de que sea incorrecto.
Problema: El alumno no pudo inscribirse, el sistema nunca le presentó el comprobante.
Razón: El alumno cerró la ventana con el resumen de datos sin oprimir el botón que decía:
"Para terminar su inscripción imprima su comprobante"
Claro que estos errores no encajan directamente con las excepciones (de hecho el del combo tampoco), pero son verídicos y muestran el tipo de cosas que podemos dar por obvias y qe el usuario no las ve.
Y el que sea un formulario de 40x40 no es pretexto. ¿Te imaginas qué pasaría si en un código de apenas unas cuantas líneas, el compilador no tuviera a bien decirnos: "Missing operator or semicolon" ¿Es obvio que los parámetros de una función deben ir separados por comas!
Pero de cualquier forma, una construcción como
jamás debe hacerse. Me parece que ya lo dijo
mamcx; al hacer esto escondes todas las excepciones posibles, no sólo las que uno prevee o piensa que pueden suceder.
Cita:
|
Empezado por dec
El usuario vuelve a abrir el formulario, esto es, vuelve a abrir el menú, selecciona la opción oportuna y se le muestra el mismo formulario de antes. Entonces el usuario escribe un número de línea o elige una y zas, se cierra el formulario y se le muestra el número de línea elegido.
|
Esto me recuerda al experimento del perrito que tiene que abrir una reja con uno de dos botones. Un botón abre la rejay el otro le da un toque eléctrico. Así has-ta-que-se-e-du-que, ¡no faltaba más!
Cita:
|
Empezado por dec
En fin. Yo creo que aquí el tema no era este en absoluto, pues al cabo todo queda reducido a cómo me parece a mí esto y cómo me parece a mí lo otro.
|
Por el contrario, yo creo que este es precisamente el tema. Abriste el hilo comentando que el mencionado artículo te había hecho por fin entender cómo se usan las excepciones y has visto qe el tema no es tan inmediato y se presta a muchos estilos y circunstancias.
El mismo artículo, a mi no me queda claro.
Cita:
|
Empezado por dec
Yo lo único que he dicho es que he cometido el error que menciona Ian Marteens en no pocas ocasiones, y, efectivamente, reconozco que en muchas ocasiones que utilizé la instrucción try/except no contaba con ningún plan B y a veces terminaba levantando la excepción mediante un Raise ¡dentro de try/except!
|
Pero, ¿cuál es el error a que se refiere Marteens? Porque a juzgar por su descripción de la cláusula
fault en Freya da la impresión de que justamente recomienda propagar la excepción. Para mi, hay excepciones que deen propagarse y otras no, depende de las circunstancias y objetivos.
// Saludos