"No claves tu programa en la posición vertical".

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

27° "NO CLAVES TU PROGRAMA EN LA POSICIÓN VERTICAL":

Una vez escribí un cuestionario falso sobre C++, en el que sugerí satíricamente la siguiente estrategia para el manejo de excepciones:

A fuerza de abundantes intentos... capturar construcciones en todo nuestro código base, a veces es capaz de evitar que nuestras aplicaciones aborten. Pensamos en el estado resultante como “clavar el cadáver en posición vertical”.

A pesar de mi ligereza, en realidad estaba resumiendo una lección que recibí en las rodillas de Dame Bitter Experience.

Era una clase de aplicación base en nuestra propia biblioteca C++ casera. Había sufrido los pinchazos de muchos programadores a lo largo de los años: las manos de nadie estaban limpias. Contenía código para manejar todas las excepciones escapadas de todo lo demás. Siguiendo el ejemplo de Yossarian en Catch-22, decidimos, o más bien sentimos, (He decidido que implica más pensamiento del que se invirtió en la construcción de éste monstruo) que una instancia de ésta clase debería vivir para siempre o morir en el intento.

Con éste fin, entrelazamos varios controladores de excepciones. Nos mezclamos en el manejo estructurado de excepciones de Windows con el tipo nativo (recuerdas ¿excepto en C++?. Yo tampoco). Cuando las cosas salieron inesperadamente, intenté llamarlos nuevamente, presionando los parámetros con más fuerza. Mirando hacia atrás, ¡me gusta!.

Piensa que al escribir un intento interno... el controlador de captura dentro de la cláusula catch de otro, una especie de conciencia se apoderó de mí de que podría haberlo tomado una vía de acceso desde la autopista de buenas prácticas hacia la aromática pero carril insalubre de la locura. Sin embargo, esto probablemente sea sabiduría retrospectiva.

No hace falta decir que cada vez que algo salía mal en aplicaciones basadas en ésta clase, desaparecieron como víctimas de la mafia en el muelle, sin dejar atrás ningún rastro de burbujas para indicar qué diablos pasó, a pesar del vertedero de rutinas que supuestamente fueron convocadas para registrar el desastre. Finalmente, hicimos un balance de lo que habíamos hecho y experimentamos vergüenza. Nosotros reemplazamos todo el desorden con un mecanismo de presentación de informes mínimo y sólido. Pero fueron muchos accidentes en el futuro.

No te molestaría con ésto, porque seguramente nadie más podría ser tan estúpido como éramos, excepto por una discusión en línea que tuve recientemente con un tipo cuyo título del trabajo académico declaró que debería saberlo mejor. Estábamos hablando de código Java en una transacción remota. Si el código fallaba, argumentó, debería detectarlo y bloquear la excepción in situ. ("¿Y luego qué hacer con éso?", pregunté. "¿Cocinarlo para la cena?").

Citó la regla de los diseñadores de UI: NUNCA DEJE VER AL USUARIO UN INFORME DE EXCEPCIÓN, más bien como si esto resolviera el asunto, ya que es en mayúsculas y todo. Me pregunto si él fue responsable del código en uno de esos cajeros automáticos con pantalla azul cuyas fotos decoran los blogs más débiles, y había quedado permanentemente traumatizado.

De todos modos, si lo conoces, asiente, sonríe y no le hagas caso, ya que avanza sigilosamente hacia la puerta.

-Verity Stob-