Cita:
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,
06-11-2015
Modo Hilado