Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 13-12-2008
noob noob is offline
Miembro
 
Registrado: sep 2008
Posts: 212
Poder: 17
noob Va por buen camino
Estoy hecho un lío con las excepciones

Tengo este bloque de código:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
begin
  if (Edit1.Text = '') or (Edit2.Text = '') or (Edit3.Text = '') then
    MessageBox( 0, 'Hay campos en blanco', 'Error', 0 )
  else
    MessageBox( 0, 'Todo está correcto', 'Información', 0 );
end;

Pero me gustaría gestionarlo mediante excepciones, la verdad es que me lío bastante con el try except end y es que tampoco le veo la utilidad si puedo usar un if else.

¿Me podéis decir como puedo transformar mi bloque de código en otro gestionado mediante excepciones?

Muchas gracias.
Responder Con Cita
  #2  
Antiguo 13-12-2008
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Hola noob,
Ese código no tiene ninguna excepción que tratar. No al menos que yo vea.
¿Que es lo que deseas hacer? es la pregunta aqui. Creo que sería fundamental que te explicases mejor sobre tu caso.

No veo un posible uso de una captura de excepción en dicho código, al menos que por la parte SI deba ejecutarse algo más que ese simple cuadro de díalogo. ¿Qué debería hacerse en caso de que no sean vacíos?

La cuestión es que el que un TEdit esté o no vacío no es motivo para una excepción. Si puede ser motivo a una excepción lo que pueda llegar a hacerse con el contenido de dichos TEdits.

Una excepción no es más que una clase heredada de TObject que sirve para dar forma al manejo de ciertos errores.

El tema no es tan fácil de comprender y explicarlo, al menos para mi que llevo unos minutos tratando de ordenar ideas para exponerlas. Te invito a que leas el capítulo 11 del libro La Cara Oculta de Delphi 4. Allí está tratada hermosamente el tema. Está a disposición de los miembros del club una copia pdf de dicho libro (su autor lo ha cedido al público para su libre distribución) en el FTP del club.

De forma breve cuando uno esta previendo el tema de una excepción y el control de la misma es porque en alguna parte del código escrito existe el riesgo de que una excepción pueda arrojarse.
Cuando se presenta, estamos hablando ya no de un caso de éxito dentro del ámbito normal y esperado. Algo ha sucedido y por tanto ahora nos hemos desviados del curso normal y esperado. Es responsabilidad nuestra el determinar que hacer en esta situación:

1. Simplemente no hacer nada y propragar la excepción. Lo que implica que el mensaje sea enviado al usuario y por tanto que exista el peligro de dejar a la aplicación en un punto inestable.
2. Capturar la excepción y ver el modo de revertir el problema con el fin de llevar al sistema a un punto estable.
3. Capturar la excepción y simplemente ignorarla por no saber como tratarla. No informando del defecto o problema al usuario.

Cuando uno hace uso de métodos, funciones, procedimientos, asignaciones, y/o eventos en delphi está firmando cierto "contrato" como dice Ian en su libro que te recomendé. Como parte del contrato, se te hace saber las clásulas. Que harás tu con ellas, allí tu. Esta clásula es la documentación que acompaña al método, función, procedimiento, asignaciones, eventos.

En la ayuda se indica que puede y no puede hacerse. En caso de que se haya diseñado el algoritmo para que notifique de los problemas mediante una excepción, en dicha documentación se hará conocer el tipo de la excepción.

Nuevamente disculpa por no poder ser muy claro en esto. En dicho documento está tratado el tema.

Cuanto más puedas comentarnos sobre tu duda más fácil será para nosotros poder ayudarte.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #3  
Antiguo 13-12-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
Yo lo tengo muy claro, aunque puede que mi método sea discutible .

creo que todo se reduce a:
- querer abortar la ejecución del programa.

Si quieres abortar, usa una excepción.
Si no, usa un MessageBox.

En tu caso no es necesario una excepción porque el código del botón no hace mucho código.

Hay veces que el código es muy complejo, y anidar los "if" junto con los MessageBox para que todo funcione correctamente hace que el código se complique, en estos casos usar una excepción puede ser más simple y funcional.

Un ejemplo didáctico:
Código Delphi [-]
type eRequerido = class(Exception);
//creo un tipo de excepción propia
...
procedure TForm1.GuardaValores;
msg := '';
for i:= 0 to tabla1.fields.count -1 do
  if tabla1.fields[i].required and tabla1.fields[i].isnull then
    msg := msg + 'campo ' + tabla.fields[i].displayName + ' es requerido' +#13#10;
if msg <> '' then
 raise eRequerido.Create(' Se necesitan valores en los siguientes campos:' + msg);
tabla1.Post;
CalcularBaseImponible;

end;

Procedure TForm1.CalculaTotal:
begin 
  try 
    GuardaValores;
  except on exception : eRequerido do
     statusbar1.text := 'No se puede calcular el total de la factura, faltan datos';
    raise;
 end;
end;
Se podría incluir un MessageBox en lugar de una excepción, pero como digo, esto es un ejemplo simple, se puede complicar más las cosas.

Llamamos a CalculaTotal:
Lo que hago es bien sencillo, primero miro si algún campo requerido está en blanco, si es así, lanzo una excepción propia con un mensaje indicando exactamente los campos vacíos que el usuario debe rellenar y en este punto, se corta le ejecución del programa, es decir, las instrucciones que están más abajo no se ejecutarán.

Pero aún hay algo más: al producirse una excepción se vuelve hacia atrás en la pila de llamadas ejecutadas, así que volverá a la rutina "CalculaTotal" y allí encuentra un bloque try ... except. Puesto que la excepción lanzada por mí es una eRequerido y coincide con la que hay escrita en el bloque try... except, se ejecuta el código, colocando un mensaje en el StatusBar. y ahora se obliga a relanzar la excepción producida con la instrucción raise; (ten en cuenta que hasta ahora no se ha mostrado el mensaje de error, de hecho los try...excepts están para intentar corregir el error y dar la posibilidad de que el programa continúe con normalidad), por tanto, se vuelve a hacia atrás en la pila de llamadas, pero ahora, desde la rutina CalculaTotal hacia atrás...

Si al volver hacia atrás en la pila de llamadas no encuentra ningún try..except llegará al nivel más alto que es el Application.OnExceptions (desde el componente TApplications de delphi puedes usarlo). Si no tienes un TApplications en tu programa, la excepción se muestra al usuario.

Si hubiesemos usado un MessageBox, en la rutina CalculaTotal no sabríamos si se ha guardado la factura o no, tendríamos que echar mano de una bandera (variable booleana que la la ponemos a true o false dependiendo si ha habido error o no al guardar) y con estas cosas se nos empieza a complicar el código, en legibilidad, claridad, etc.

Como bien dices, ya que el botón lo único que hace es chequear si todo está correcto o no, no tiene sentido lanzar una excepción. La excepción se lanza para que no ocurra un mal mayor.

Espero haya sido claro.... que va a ser que no

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.

Última edición por Lepe fecha: 13-12-2008 a las 08:47:48.
Responder Con Cita
  #4  
Antiguo 13-12-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
Cita:
Empezado por Delphius Ver Mensaje
3. Capturar la excepción y simplemente ignorarla por no saber como tratarla. No informando del defecto o problema al usuario.
Sólo comentar que esa opción tiene mucho peligro:
- el programa no hace lo que se espera
- no sabes que ha ocurrido un error.
- no sabes cómo arreglarlo.

Si no sabes cómo arreglarlo, no lo toques ... quiero decir, es mejor ver la excepción en pantalla o enviarlo a un archivo .log que ignorarla definitivamente. Si la VCL ha lanzado una excepción... por algo será

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
  #5  
Antiguo 13-12-2008
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Cita:
Empezado por Lepe Ver Mensaje

creo que todo se reduce a:
- querer abortar la ejecución del programa.

Si quieres abortar, usa una excepción.
Si no, usa un MessageBox.
Me gusta esa descripción simple: para abortar.

Cita:
Empezado por Lepe Ver Mensaje
Sólo comentar que esa opción tiene mucho peligro:
- el programa no hace lo que se espera
- no sabes que ha ocurrido un error.
- no sabes cómo arreglarlo.

Si no sabes cómo arreglarlo, no lo toques ... quiero decir, es mejor ver la excepción en pantalla o enviarlo a un archivo .log que ignorarla definitivamente. Si la VCL ha lanzado una excepción... por algo será

Saludos
Bueno amigo, yo dije opciones. No es una buena elección como bien lo mencionas, pero en fin de que se puede optar por esa opción se puede.

Por cierto. Si se hace uso de un Log de excepciones lo mejor es que sea un singleton. Es decir, que exista un sólo punto en donde se traten a las excepciones. Todas las excepciones van a un mismo objeto TLog, por ejemplo, y son guardadas en un único archivo.

Aunque en ocasiones, no es buena opción. Más si tiene pensando en trabajar con muchos archivos .log.

De igual manera, en ocasiones ante casos de éstas excepciones raras y a las que no sabemos tratar lo mejor es tener un "cuadro de diálogo único" por donde comunicarlas.

Lo que si es una buena opción a tener en cuenta es la de convertir excepciones a un grado de abstracción adecuado y entendible para la clase que la recibe. Por ejemplo, supongamos que tenemos las clase A, B y C. A para trabajar se comunica con B, y B con C. A cuenta con un método MA, y en el cual se procede a una comunicación lineal hasta C. Es decir, MA invoca a un método MB, y MB a uno de MC. Ahora MC lanza una excepción EC, que la captura MB. Esta excepción a A no le corresponde el adecuado grado de abstracción, por tanto B "convierte" a esa excepción EC a una excepción EB, añadiendole la información necesaria para que A sepa como tratarla y se la transmite a A.

Espero que me entienda,

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #6  
Antiguo 13-12-2008
noob noob is offline
Miembro
 
Registrado: sep 2008
Posts: 212
Poder: 17
noob Va por buen camino
Sí mi código es demasiado simplón para que pueda ser reescrito mediante excepciones.
Pongo otro:

Código Delphi [-]
MySQL50Connection1.Open;

MySQL50Connection1 es un componente que se conecta a un servidor MySQL.

Si todas las propiedades de ese componente (HostName, Port, UserName, Password, DatabaseName) están bien establecidas entonces se conectará al servidor MySQL sin problemas pero si no lo están, por ejemplo no hemos equivocado al introducir la contraseña el programa cascará y la ejecución se detendrá.

Lo que yo quiero es controlar este aspecto y en vez de que casque que se envíe un mensaje al usuario pero que la ejecución no se detenga.

Según lo que habéis escrito pienso que podría ser algo así:

Código Delphi [-]
try
  MySQL50Connection1.Open; // inténtate conectar al servidor MySQL
except
  ShowMessage('No he podido conectarme'); // en caso excepcional, si no puedes conectarte dímelo
end;

Pienso que algo falta porque no he usado raise ni tampoco he hecho except on.

¿Me ayudáis a completarlo?

Saludos.
Responder Con Cita
  #7  
Antiguo 13-12-2008
Avatar de ElKurgan
[ElKurgan] ElKurgan is offline
Miembro Premium
 
Registrado: nov 2005
Posts: 1.237
Poder: 20
ElKurgan Va camino a la fama
Primeramente, estoy con el amigo Delphius: El capítulo mencionado del libro de la cara oculta es la mejor forma de entender el como y el porqué de las excepcines.

Por lo demás, si lo que quieres es mostrar un mensaje entendible sobre lo que ha sucedido, con lo que has puesto en tu código te vale perfectamente. Si lo que qieres es mostrar el mensaje pero además que el propio sistema te gestione la excepción original bastaría con añadir la clausula "Raise" después de showmessage, para que la excepción siga propagádose a lo largo del programa, hasta el gestor final.

Un saludo
Responder Con Cita
  #8  
Antiguo 13-12-2008
Avatar de ContraVeneno
ContraVeneno ContraVeneno is offline
Miembro
 
Registrado: may 2005
Ubicación: Torreón, México
Posts: 4.738
Poder: 24
ContraVeneno Va por buen camino
Código Delphi [-]
try
 MySQL50Connection1.Open; // inténtate conectar al servidor MySQL 
except 
 on E:Exception do begin
  ShowMessage('No he podido conectarme debido a: ' E.ClassName + ' - '+ E.Message); // en caso excepcional, si no puedes conectarte dímelo 
 end; //except
end; //try


Eso sería muuuuy general y poco recomendable, ya que podría pasar cualquier cosa y aparecería el mismo mensaje. Lo mejor es utilizar una clase de excepción y una acción específica para cada cosa:

Código Delphi [-]
 try
 MySQL50Connection1.Open; // inténtate conectar al servidor MySQL 
except 
 on E:EDBEngine do begin
  //manejo en caso de error de base de datos
 end; //DNEngine
 On E:EAccessViolation do begin
  //Manejo de error en acceso de memoria
 end; //AccessViolation
end; //try
__________________

Responder Con Cita
  #9  
Antiguo 13-12-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
Un detallito... Tu código no es simplón, es que testea una serie de condiciones y actua en todos los casos posibles (con un MessageBox, pero hace algo), por eso quizás no he entendido tu objetivo principal.

Pensando de forma global (abstracta que dirían algunos) tu último ejemplo está bien, ya que se trata de saber si se puede conectar o no con MySql.

Si quieres obtener información detallada de por qué no se ha podido conectar, tendrás que mirar los tipos de excepciones que lanza MySql y detectar el código de cada uno, a partir de ahí personalizar los mensajes.

Si quieres detalles, usa on except y el tipo de excepción de MySql. Lo mismo es aplicable para el trabajo de excepciones en general, siempre puedes usar un código general (para todos los tipos de excepciones) y otro más concreto para excepciones con un código de error.

Lo más rápido para ver el tipo de error producido es:
Código Delphi [-]
try
  MySQL50Connection1.Open; // inténtate conectar al servidor MySQL
except 
  on e:exception do
    ShowMessage(e.ClassName); // en caso excepcional, si no puedes conectarte dímelo
end;

A ver si un compañero que trabaje con MySql puede ponerte un código de ejemplo.

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Estoy hecho un lio con los codigos de barra. Help!! escullar Impresión 28 21-02-2007 04:17:52
Excepciones banleu Firebird e Interbase 8 20-04-2006 01:11:18
Excepciones Acker Tablas planas 6 06-08-2005 16:22:18
excepciones!!!!! hanna33 OOP 3 24-05-2005 18:10:10
Excepciones del bde Pablo Carlos Conexión con bases de datos 3 15-04-2005 18:57:46


La franja horaria es GMT +2. Ahora son las 01:36:13.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi