Con el paso del tiempo en mi experiencia laboral (la cual ya cuenta con algunos años en el desarrollo de aplicaciones) y después de interactuado con diferentes personas, equipos ó diferentes empresas, siempre guardo algunos recuerdos de los proyectos en los que he participado. Y el simple hecho de haber participado y ser testigo de toda una gran variedad en la toma de decisiones que se ha aplicado al momento de intentar resolver un problema de implementación mediante el código fuente final, los cuales ( ya sea de forma consciente o inconsciente) es muchas ocasiones resulta ser que se tomó una muy mala decisión, que en ocasiones generan más problemas ó que simplemente no aportando nada al resultado final. Creo que a muchos nos ha pasado, cierto? Y más cuando se revisa código de terceros, cierto?
Es debido a este andar por varios proyectos que tome la decision de crear mi propio compendio de bloques de códigos “peculiares” (ya sea horrores, antipatrones, etc.) que debido a su estructura y contenido me han causado asombro, lagrimas y con frecuencia risas.
Como elemento de inicio he seleccionado el siguiente patrón de código que he denominado “Double Play Try/Catch”, y para tratar de explicarlo una breve introducción:
Imagina a un desarrollador al que se le asigna agregar el manejo de excepciones a un bloque de código y con base a su gran “iniciativa” ha decidido hacer una implementación tratando de aplicar las “Best Practices” que leyó en alguna revista. Una vez puestas las manos en marcha realiza la implementación logrando con ello algo muy parecido a lo siguiente:
MyFunction(…)
Try
something()
Catch Exception ex
Throw ex
Al final sin querer el desarrollador termina aplicando un antipatrón que en mi caso he nombrado el “Double Play Try /Catch”. El nombre lo he tomado de una famosa jugada del Béisbol conocida como el DOUBLE PLAY, en donde dos jugadores de ofensiva son puestos OUT al momento de una jugada continua (aunque en nuestro ejemplo parece ser que el out es así mismo).
Para el caso del bloque de código anterior, en el manejo de excepciones implementado se “atrapa” una excepción en la primer sentencia Catch (Primer OUT) y se decide volver a lanzar nuevamente la misma excepción, esperando que en algún punto más adelante se logre atrapar nuevamente a dicha excepción (Segundo OUT) y DOUBLE PLAY!.
Con lo anterior, es por demás decir que se trata de un manejo totalmente INCORRECTO de las excepciones y debido a su estructura y logica? simplemente no tuvo ningún caso el bloque Try/Catch.
La generación de una excepción tiene un costo ALTO en el procesamiento y performance de las aplicaciones; por tanto es muy importante tener mucho cuidado al momento de aplicar un manejo adecuado y tomar en cuenta las siguientes consideraciones:
a) Agregar un manejo de excepciones no es una cuestión de performance, solo de buenas costumbres al momento de prevenir flujos excepcionales, pero como todo en EXCESO puedo ser contraproducente.
b) El manejo de excepciones debe de proporcionar información detallada sobre los síntomas que provocan el flujo Excepcional, con la intención de ofrecer alternativas sobre como intentar reaccionar a ellas, el simple hecho de colocar un bloque Try/Catch no soluciona nada.
c) Las excepciones tienen un impacto en el performance y por tanto no es conveniente tratarlas como un mecanismo de decisión en la lógica de procesamiento!, en cuanto te sea posible mejor evitarlas.
Finalmente algunos recursos que permiten explicar el costo de las excepciones y algunas buenas recomendaciones sobre su manejo:
- Design Guidelines: Exception Throwing por Krzysztof Cwalina
- Error Handling
- When you can´t throw an exception
En fin, conforme vaya recordando vivencias o encontrando en mi recorrido algunos bloques de código “interesantes” por supuesto que los intentare clasificar y anexar a este compendio.
