Capturar Excepciones

[roman]

Yo no comparto la visión que tienen de las excepciones. El manejo de la excepción no es quien corta abruptamente la ejecución sino la excepción misma, si es que se ve la diferencia.

Es cierto que hay un abuso de las excepciones al grado de usarlas a modo de condicional y en muchas ocasiones bastaría examinar el valor de retorno de una función.

Sin embargo, las excepciones son un objeto mucho más complejo que eso, siendo su gran virtud el efecto burbuja, esto es, que la excepción se va elevando hasta encontrar un punto en donde se puede manejar por quien pueda y sepa hacerlo. Lejos de ser una interrupción brusca del código, en realidad el manejo de excepciones es quien permite manejar un problema de la forma más decorosa posible.

Como dije antes, no hay que abusar de las excepciones. El caso que se planteó aquí originalmente (me refiero al de este año no al del inicio del hilo) es un típico caso de abuso de la técnica: se usa la excepción como un condicional para tomar una decisión que, en realidad, tiene que ver más con la lógica de negocios que con el flujo de la aplicación.

// Saludos

[[Lepe]]

No os hacéis la idea de lo que echo de menos estas charlas donde se derrocha conocimientos, gustos, opiniones, pero siempre desde el entendimiento y buen hacer .

Más de 12 años en Club delphi y sigo disfrutando como un crío....Sí, hoy tengo el día tonto

Un abrazo!!

[Casimiro Notevi]

Empezado por Lepe

No os hacéis la idea de lo que echo de menos estas charlas donde se derrocha conocimientos, gustos, opiniones, pero siempre desde el entendimiento y buen hacer .
Más de 12 años en Club delphi y sigo disfrutando como un crío....Sí, hoy tengo el día tonto
Un abrazo!!

Eso es estupendo

[roman]

Empezado por Lepe

No os hacéis la idea de lo que echo de menos estas charlas donde se derrocha conocimientos, gustos, opiniones, pero siempre desde el entendimiento y buen hacer .

Pues no te alejes mi estimado Lepe. Aunque ahora programes en VB, te seguimos queriendo

// Saludos

[[Delphius]]

Empezado por Ñuño Martínez

Otra posibilidad es crear un "modo depuración". Si este está activo, entonces muestra toda la información de la excepción capturada (por ejemplo, llamando a TApplication.ShowException), y si está desactivado sólo muestra un mensaje más corto pero guardando el resto de información. Sería algo así como:
Código Delphi [-]TRY ... EXCEPT ON Error: Exception DO BEGIN IF Config.Depurando THEN sysutils.ShowException (Error, ExceptAddr) ELSE Application.MessageBox ('No pudo realizarse la operación', 'Error'); Application.Log (etError, Format ('[%s] %s at %p', [Error.ClassName, Error.Message, ExceptAddr])); END END;


Nota importante: Acabo de fijarme en que la clase Exception definida por Free Pascal difiere ligeramente de la descrita por Delphi, y lo mismo pasa con otras clases y funciones relacionadas, así que puede variar un poquito la cosa. Aun así creo que queda clara la idea, ¿no?

Interesante enfoque. Pregunto yo... ¿No existe una directiva de compilación tanto en Delphi como en Lazarus para determinar cuando se está en modo debug, y/o que se pueda (des)activar según se necesite? ¿O realmente se necesita de recurrir a cosas como la de tu ejemplo?
Otra cosa, ¿En que difieren Delphi y Free Pascal en la clase Exception? Yo dejé Delphi por Lazarus, pero no me puse a ver en detalle que cosas varían entre cada IDE... empleo las excepciones y no he visto en que se diferencian y ahora me queda la intriga.
Lo que era nuevo para mi es la función ExceptAddr.

Saludos,

[mamcx]

Lo que veo en el ejemplo de Ñuño es un intento de replicar lo que hace una libreria de logging solida, que permite hacer cosas como:

Código Delphi [-]

log.info("A")
log.warning("B")
log.debug("C")

Y se puede setear que los log solo se muestren en el nivel deseado.

Pero eso es tangencial al problema propuesto en este hilo. Osea, un log no tiene que ver con control de flujo.

[[AgustinOrtu]]

Hasta donde se en Delphi existen las directivas {$RELEASE} y {$DEBUG}. Pero no creo que se puedan activar o desactivar como la RTTI {$M+} y {$M-} por ejemplo

[Ñuño Martínez]

Empezado por roman

Yo no comparto la visión que tienen de las excepciones. El manejo de la excepción no es quien corta abruptamente la ejecución sino la excepción misma, si es que se ve la diferencia.

Es cierto que hay un abuso de las excepciones al grado de usarlas a modo de condicional y en muchas ocasiones bastaría examinar el valor de retorno de una función.

Sin embargo, las excepciones son un objeto mucho más complejo que eso, siendo su gran virtud el efecto burbuja, esto es, que la excepción se va elevando hasta encontrar un punto en donde se puede manejar por quien pueda y sepa hacerlo. Lejos de ser una interrupción brusca del código, en realidad el manejo de excepciones es quien permite manejar un problema de la forma más decorosa posible.

Como dije antes, no hay que abusar de las excepciones. El caso que se planteó aquí originalmente (me refiero al de este año no al del inicio del hilo) es un típico caso de abuso de la técnica: se usa la excepción como un condicional para tomar una decisión que, en realidad, tiene que ver más con la lógica de negocios que con el flujo de la aplicación.

// Saludos

No, si yo uso las excepciones como tú dices. Intento capturarlas lo antes posible en lugar de que "se caigan" del programa.

[roman]

Yo creo que ni tan rápido ni tan lento. Todo depende de la situación. Puedes programar una biblioteca que lance alguna excepción y la aplicación que la use será la encargada de manejarla. Por ejemplo, en el ámbito web, una excepción puede generarse al acceder a una base de datos y sólo la aplicación final sabrá el momento adecuado para manejarla y desplegar el mensaje que considere pertinente al usuario.

Esto proporciona una forma limpia de manejar los errores impredecibles. Mucho más limpia que estar acumulando los resultados de funciones. Es la gran ventaja sobre los métodos antiguos.

// Saludos

[mamcx]

Empezado por roman

.. Todo depende de la situación... Mucho más limpia que estar acumulando los resultados de funciones.

Procesar uno a uno los errores no es tan practico en todos los casos. Validar un formulario es el ejemplo clásico: Lo ideal es reportar todos los errores. En cambio, si falla la conexión a un recurso remoto no tiene sentido seguir generando mas errores. Asi que *estar acumulando los resultados * tiene sentido en los casos en donde las validaciones pueden ser paralelas y cuando el error siguiente no depende del estado del anterior.

Es por eso que el manejo de los errores en los lenguajes es algo "cojo", ya que normalmente estan fijado en un unico caso de uso. Curiosamente, el modelo UNIX con su STDERR/IN/OUT es ideal...

[mamcx]

Wow, coincidencialmente este articulo apareció hoy en reddit, que habla del tema:

http://mortoray.com/2015/11/06/every...unctions-fail/

[[AgustinOrtu]]

Acá se puede ver en accion como "validar formularios" (o mas tecnicamente, como dice mario, validaciones en paralelo), el chico lo hace utilizando atributos y queda bastante limpio y facil de mantener

[[Delphius]]

Empezado por mamcx

Lo que veo en el ejemplo de Ñuño es un intento de replicar lo que hace una libreria de logging solida, que permite hacer cosas como:

Código Delphi [-] log.info("A") log.warning("B") log.debug("C")


Y se puede setear que los log solo se muestren en el nivel deseado.

Pero eso es tangencial al problema propuesto en este hilo. Osea, un log no tiene que ver con control de flujo.

Vuelve a leer el hilo, y sobre todo el código propuesto por Ñuño y dime donde ves que está implementando un sistema de Log de error.
En ningún momento lo hace. Se comentó que el uso de las excepciones y su captura puede ser útil para llevar un log, pero el ejemplo de Ñuño no sugiere nada de eso.
Lo que sugiere es disponer de una clase, registro, o algún tipo definido que tenga a modo de flag para definir si está en modo de depuración o no y aportar má o menos información sobre el error detectado.

Otro tema que me animo a exponerte es tu enorme fanatismo para intentar calzar a delphi a que haga o trabaje como lo hace otro lenguaje. Lo haces en cada intervención tuya. No mezcles peras y manzanas. Deja a cada lenguaje a que implemente su propio modelo y forma de hacer las cosas. No necesariamente está mal uno u otro. Simplemente no son comparables, ninguno es el malo o el bueno de la película.

Volviendo al hilo, o al menos, parte del tema discutivo al momento de reavivar el hilo es que como dice roman: se está forzando a redigirir una cuestión de lógica de negocio con el de flujo del programa.

Las excepciones deben planificarse bien. Si tienes planeado lanzar una excepción según un condicional, hay que pensarlo dos voces... ¿Hasta que punto se desea propagar? ¿Que se está por interrumpir? En ocasiones abusamos de las excepciones, cuando deberíamos repensar mejor el diseño y proponer otra forma de indicar que ha ocurrido un error.

Saludos,

[[Delphius]]

El punto es que una excepción es eso: ¡Algo inesperado, que no hemos contemplado o que al menos no esperamos que debiera suceder de alguna forma o en ciertas condiciones!
Emplear un condicional para evaluar si lanzamos una excepción que puede tener un significado en el contexto de negocio está mal.
Hay que diferenciar lo que es un mero aviso al usuario, de lo que es en realidad una excepción y para que en realidad fueron diseñadas.

Saludos,

[mamcx]

Empezado por Delphius

Vuelve a leer el hilo, y sobre todo el código propuesto por Ñuño y dime donde ves que está implementando un sistema de Log de error.

Código Delphi [-]
ON Error: Exception DO
  BEGIN
    IF Config.Depurando THEN
      sysutils.ShowException (Error, ExceptAddr)
    ELSE
      Application.MessageBox ('No pudo realizarse la operación', 'Error');
    Application.Log (etError, Format ('[%s] %s at %p', [Error.ClassName, Error.Message, ExceptAddr]));
  END

Nota el comentario: "Lo que veo en el ejemplo de Ñuño es un intento de replicar...". No quise decir que estaba haciendo un sistema de Log, sino que replica lo que hace uno de estos, osea, un sistema de log permite hacer llamadas a "info", "debug", "warning", y potencialmente llegar a lo que se esta mostrando: Si quiero, cuando sea "debug" mandalo a consola op archivo y si es "warning", mostrar un mensaje o lo que sea.

O dicho de otra forma, es una implementacion de lo que hace Ñuño!

Re-leyendo veo que me falto aclarar porque rayos menciono el punto, y es que hablaste de usar las directivas de compilacion con relacion a esto. Y cuando preguntas:

¿O realmente se necesita de recurrir a cosas como la de tu ejemplo?

Es algo que es obvio cuando uno esta acostumbrado a usar una libreria de LOG, pero no tanto en el ejemplo propuesto. Osea: Porque usar una condicional en vez de usar la directiva de compilacion? Porque los errores/mensajes no son todos iguales y tienen diversos niveles: Asi como hay "warnings" y "error" a la hora de compilar, una app puede lanzar una excepcion, pero estas son "warnings" otras son "errors" otras son "catastrophic errors" otras son "ignorables/infos", etc, y es el programador y no el compilador que determina a que nivel asignar cada cosa. Lo mismo decir que una excepcion es parte de la logica de negocio, o interna, o que es algo pal' usuario o solo para el desarrollador.

Solo que en el ejemplo de codigo, se esta asumiendo (que ademas es muy normal) que en modo DEBUG solo existe el desarrollador. Y es muy practico en tiempo de ejecucion, sin usar IDEs, setear la app a modo "debug" para diagnosticarla cuando esta corriendo donde el cliente: Cosa que es lo que se hace con una libreria de log robusta Y esa era la conexion que pobremente intente hacer!

Otro tema que me animo a exponerte es tu enorme fanatismo para intentar calzar a delphi a que haga o trabaje como lo hace otro lenguaje. Lo haces en cada intervención tuya. No mezcles peras y manzanas. Deja a cada lenguaje a que implemente su propio modelo y forma de hacer las cosas. No necesariamente está mal uno u otro. Simplemente no son comparables, ninguno es el malo o el bueno de la película.

Sorry. La intención de mostrar como se hace en otros entornos es tratar de dilucidar otras formas de hacer las cosas... Tambien es que asi como cuando programo a veces me veo intentando escribir un lenguaje cuando estoy en otro, se me cruzan los cables cuando hablo de ellos. Pienso que existe un lenguaje, que es superior a todos, pero que solo esta de forma parcial en cada uno.. y me pregunto como hacer que lo mejor de unos llega a los otros que uso...

[roman]

Empezado por mamcx

Validar un formulario es el ejemplo clásico: Lo ideal es reportar todos los errores. En cambio, si falla la conexión a un recurso remoto no tiene sentido seguir generando mas errores. Asi que *estar acumulando los resultados * tiene sentido en los casos en donde las validaciones pueden ser paralelas y cuando el error siguiente no depende del estado del anterior.

Sip. Estoy de acuerdo contigo. Una falla en la conexión es una excepción. Un dato incorrecto de un formulario no.

// Saludos