FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Excepciones: uso y abuso de la instrucción try/except
Hola,
He dudado entre publicar este Hilo o no y es que lo que diré es, desde luego, interesante para mí, pero, no sé hasta qué punto podrá o no importarle a alguien más. Brevemente. Hasta anoche no supe bien el uso de la instrucción try/except no ya en Delphi, pero, supongo, en cualquier lenguaje que haga uso de esta instrucción o alguna similar. Algo he leído (reconozco que no lo que debiera) sobre el tema, empero, hasta anoche, tal como digo, no vi la luz, como suele decirse. Me alumbró Ian Marteens en un artículo suyo titulado Excepciones en Freya. Resulta que, como el autor menciona en el segundo o tercer párrafo del artículo susomentado: Cita:
Cita:
Pues nada. Que les recomiendo el artículo en cuestión y que espero que estos párrafos no sean del todo inútiles para quien los lea. Ah, casi se me olvidan: gracias a Ian Marteens por este y otros textos suyos. |
#2
|
||||
|
||||
No entendí. ¿Se supone que hay que usar siempre raise para propagar la excepción? En tal caso no me parece lógico. Si la excepción se arregla ¿qué es lo que seguimos propagando?
// Saludos |
#3
|
||||
|
||||
Hola,
Cita:
|
#4
|
||||
|
||||
Cita:
De cualquier forma todo este asunto del plan B me parece un poco raro. No es si tienes o no un plan B, es que debes tener un plan B, de una forma u otra; si hay un código susceptible de generar una excepción, entonces debes manejarla de alguna manera. // Saludos |
#5
|
||||
|
||||
Hola:
Yo siempre utilizo Try...Except, no sé para que sirve el raise..alguien sabe??
Saludos y hasta pronto.. |
#6
|
||||
|
||||
Hola.
Lucasarts nos ha dado un buen ejemplo de uno de los errores mas comunes a la hora del uso de try/except. Cita:
Supongamos por ejemplo, que la propiedad Year, aún cuando es de tipo string, valida que el valor asignado sea un número. La forma "normal" de "romper un contrato" (sigo con marteens) es elevar una excepción, dado que este no se ha cumplido al asignar la cadena "mil novecientos noventa y cinco" a la propiedad year (lo introducido por el usuario). En este caso la excepción será de la clase EConvertError. En este caso, el usuario segirá recibiendo el mensaje: Para cambiar el tag de un archivo,éste no debe estar ejecutandose Esto no orienta en nada al usuario a corregir su error. Hay que tomar en cuenta también que hay otra serie de excepciones que podrian ocurrir: El disco está lleno, quizas tenga sectores dañados. En windows no es inusual que el sistema se quede sin recursos... también podria ocurrir una guerra nuclear y el usuario obtendría siempre el mismo mensaje . Esto nos lleva a la situación mas general de comprender que podrá ocurrir una serie de condiciones de excepción para la que no estamos preparados. La regla general es entonces aplicar el "plan b" solo para aquellas que sabemos y queremos tratar, dejando pasar todas las demás.
Suponiendo que el método elevará la exepción EFileInUse. Ahora, cualquier otra condición de error seguirá abortando la ejecución del código hasta que haya un bloque que si sepa que hacer con ella. Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#7
|
||||
|
||||
Para medio aclarar (que con plan A y plan B ya me dan ganas del plan C ):
El asunto con try..except es muy simple, realmente ... Uno solo debe usar except si: 1- Es un codigo transaccional: ie. Hay una serie de tareas, un commit y en caso de falla, un rollback. 2- Cuando la excepcion se usa para CORREGIR el problema. Ej, estamos haciendo una conexion a un lugar remoto, y nos salta un error. Supongamos un timeout, y el programa es un cliente FTP que aparte de timeout tiene reintentos... Si la conexion falla se puede corregir (o sea volver a conectar) hasta N reintentos Pero lo que nunca se debe olvidar (porque las dos reglas anteriores no son absolutas, y se puede resolver la segunda no con excepciones sino con funciones que devuelvan el resultado de la operacion) es que: JAMAS SE DEBE ESCONDER EL ERROR. NUNCA. Y eso es todo lo que hay que saber. Ya sea que se de "rollback" o que se "corriga" se debe NOTIFICAR que hubo error, ya sea por medio de un log, un mensaje (no intrusivo, en el caso de la correccione: e.j: El cliente FTP simplemente pone un mensaje que dice: La conexion falla, reintentando en 30 segundos...), un mesagebox o lo que sea. Si se esconde el error como: try AbrirArchivo; except result := false; Nos va a dar un total dolor de cabeza el luego adivinar que salio mal. Como siempre he dicho: Si el programa saca error, es que esta bueno (Miedo al que nunca lo saca!)
__________________
El malabarista. |
#8
|
||||
|
||||
Hola,
Cita:
Voy a trasladar aquí un buen trozo del artículo en cuestión, que en realidad es el meollo del mismo, al menos, en lo que se refiere a lo que traté yo de declarar en este Hilo: Cita:
Cita:
Piensa que se trata, en el ejemplo anterior, de mostrar un pequeño formulario que solo contenga un ComboBox, en el cual el usuario tuviera que elegir/escribir un número de línea a la que luego nosotros dirigirnos. Imagina que al usuario le da por escribir un caracter en lugar de un número en el ComboBox. ¿Para qué mostrarle el error? ¿es que no es evidente? ¿es que el usuario no ve por sus propios ojos que una línea se representa mediante su número y no una letra u otro caracter? Personalmente, en este caso, al menos, no muestro ningún error, ni siquiera creo que interese mostrar la excepción: simplemente ignorarla. El usuario percibirá rápidamente, en mi opinión, que la "acción" al cabo no produjo nada, y todo lo más mostrará de nuevo el formulario, verá que hay solamente números en donde escoger "cargados" en el ComboBox y escogerá uno, si quiere. Quiere decirse que, en este caso, repito, no creo interesante mostrarle el "EConvertError", porque es más que evidente para el usuario lo que realmente está ocurriendo: por si no lo fuera del todo, en cuanto se limite a escribir o elegir un número verá cómo todo va tal como se espera. Y aquí se ve a las claras que no hay plan B de por medio. Un plan B, por ejemplo, sería decir "muy bien, usuario, no sé qué escribiste que estoy aquí, dentro de la excepción, pero, para estos casos, tengo preparada una pequeña sorpresa: me dirigiré a la línea 0, para que te chinches". Eso ya sería un plan B, que, como puede verse arriba, no existe en este caso: el error, la excepción, simplemente es ignorada y punto pelota. Última edición por dec fecha: 15-07-2005 a las 15:00:52. Razón: (corrección del texto) |
#9
|
||||
|
||||
Cita:
Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#10
|
|||
|
|||
Ayuda con Try...Except
Hola estoy tratando de hacer un programita que me escanee la red y que me borre el documents and settings de las maquinas encontradas. Mas o menos he logrado parte de esto, pero me da error cuando trata de borrar al usuario que esta logueado y algunos otros. Quisiera saber de que forma se puede evitar estos errores para que el programa no se detenga y continue borrando. Es decir como se usaria el try...except aqui.
|
#11
|
||||
|
||||
jejeje
¿cuanto tardarán? |
|
|
|