Ver Mensaje Individual
  #11  
Antiguo 29-10-2015
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Reputación: 29
Lepe Va por buen camino
Cita:
Empezado por AgustinOrtu
Voy a dar mi apreciacion:
... Pues yo también, ya que estamos en un foro de programación y de eso se trata, de compartir información y opiniones

El tratamiento de las excepciones es un libro gordo aparte jejeje.

Mi punto de vista es distinto. Al usuario hay que darle un mensaje amigable, pero aprovecha ese mismo try except para escribir en un fichero log el error, la clase, la línea donde se produce, etc.

Cuando programas es otro mundo, desde hace mucho tiempo se usan las directivas de compilación para eso, aunque los BDS lo popularizaron con el compilar para "release" o para "Debug", ya de sobra conocidos en los XE.

Cnpack ya lo incluye en Delphi 7 con su depurador CnDebug y es bastante fácil hacerlo.

Todo este rollo viene porque en el except, la rutina que hace un log, puedes incluir:
- Si el IDE de delphi está en ejecución, entonces dame toda la información que necesito como programador, Nombre de tabla, campo, valor por defecto, clase del error, etc. y pégame un pantallazo con toda esa información. Incluída la pila de llamadas de la aplicación, porque muchas veces el error está en 3 procedimientos atrás, no en la linea que levanta el error.

- Si el IDE no está, pues escribes en un fichero de log de la aplicación, la hora fecha y toda la información que quieras, pero al usuario déjalo vivir leyendo un mensaje comprensible para él.

- Si la directiva de compilación está anulada (porque la desactivo antes de compilar la versión definitiva), ese código no va en el ejecutable y no molesta ni afecta al rendimiento.

Teniendo todos estos ingredientes, es muy fácil ordenar las cosas. Gestionar las excepciones es hacer otro programa aparte:
- herencia de las excepciones (crear tu propio árbol de excepciones tal y como haces con las clases de delphi). Algo que he pensado sobre la marcha y espero aclare lo que digo:
Código:
 EMiprograma (hereda de Exception)
      EBBDD  -> excepciones de la base de datos
          EAdministrador -> Error que solo subsana el administrador de la BBDD, 
                          o sea, el programador, cosas que nunca deberían ocurrir, pero ocurren: "shit happens"
      EFacturar (hereda de EMiprograma) y ocurren en el módulo de facturación
Cada subnivel de excepciones, tiene sus propiedades e información que puede ayudar a encontrar el error...

- Si se han de mostrar o no al usuario (heredar de EAbort o de Exception).

El concepto es muy simple y poderoso, una vez se levanta una excepción, va subiendo por la pila de llamadas de tu aplicación ejecutando el try ... except que lo contenga, si incluye un "raise ; " seguirá subiendo hasta llegar al nivel más alto, el TApplication.OnException, si no tienes ese componente en tu aplicación, el mensaje se muestra al usuario. Si tienes el componente, tú decides qué hacer en ese evento.

Es cierto que una excepción tiene un coste:
- Se corta el flujo normal del programa (saltos incondicionales del código, cambio de los valores de los registros de la CPU, cambio del contador del programa, etc...)
- Se crean objetos que recopilan información extra.

Pero en mi opinión, debido a la complejidad de las aplicaciones actuales (multiplataforma, con componentes de terceros, etc), ya no son casos tan "excepcionales", ocurren demasiado a menudo y tenemos que saber manejarlos.

Por supuesto el típico "On E:Exception do" hay que erradicarlo, debemos controlar solo las excepciones que realmente nos interesan... como en este caso "On E: EUniError do".

Estoy de acuerdo con AgustinOrtu que más vale prevenir que curar, es decir, si se puede evitar lanzar una excepción inhabilitando un botón en la pantalla de usuario, ocultar ese registro en pantalla o hacerlo de solo lectura... perfecto. Por otra parte, si un sistema Gestor de Bases de Datos, tiene excepciones, es porque ha hecho falta crear ese sistema de notificaciones.

Hay sistemas donde se escribe más código en la BBDD que en el programa Delphi, y en ese caso lanzar una excepción, capturarla en un trigger o procedimiento almacenado y actuar en consecuencia, es la solución perfecta.

Las herramientas las tenemos ahí, ahora solo hay que usarlas cuando "creamos que es necesario", y lo entrecomillo porque a veces, por desconocimiento, las usamos cuando no debemos, pero nos soluciona el problema.

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 Casimiro Notevi fecha: 29-10-2015 a las 21:21:10.
Responder Con Cita