Excepciones hoy día

Publicado en Blog · 07 marzo 2016.
Las excepciones son peligrosas

Dicen que hace miles de años el miedo era un buen indicador de pelígro. Gracias a él, podíamos evitar caer en las fauces de un gran león o hundidos bajo torrentes de agua. Hoy día, salvo ciertas circunstancias en que sigue siendo útil, la más de las veces es un gran quebradero de cabeza para la mayoría de las personas. El motivo está bien claro, el mundo ha cambiado pero ese indicador de problemas no se adaptó a él. Sí, antes era útil ya que te protegía de peligros y ahora..... ahora puede crearte ansiedad, estréss o que te incapacite para montarte en un ascensor o no te atrevas a decirle a la chica que te gusta lo que sientes.

Eso también ha pasado con la informatica. Hay muchas cosas( patrones, estructuras de control, ... ) que antes servían bajo ciertas circunstancias y que hoy no son adecuadas e incluso pueden tornarse como perjudiciales. Todos los que tuvieran un AMSTRAD seguro que se acordarán del entrañable GOTO. ¿Imaginarse un programa sin ese querido amigo nuestro ?,¡ imposible !. Con el paso de los años la tecnogía cambio y el pobrecito se refinó en algunos casos pero se vio que era mejor su desaparición para evitar más espaguetis.

Eso ha pasado con las excepciones y, al contrario que al GOTO, la mayoría lo defienden. No tiene lógica....

Como sabrás, las funciones y objetos se basan en ocultar su funcionalidad. Es decir, no me importa cómo lo haga pero si le doy unos datos, quiero otros como resultados, obtenidos de la operación que dice saber hacer. Esto es importante porque así no hay acoplamiento, es decir, tú puedes cambiar tu forma de actuar sin que yo necesite cambiar mi código. Con las excepciones esto no es así, ¿ porqué tengo que saber yo que que a la hora de crear un usuario, la validación del DNI se hace contra una base de datos y puede dar una excepción de conexión a la base de datos ?¿ y si mañana lo hace por servicios web tendré que cambiar mi código para adaptarlo ?. ¿ Por qué tengo que saber que una división por cero no es válida ?.

Existen los dominios de los datos del problema, correcto. Pero, todo mi código no tiene necesidad de saberlo. Hace muchos años, un usuario lanzaba un comando y si no era válido podías lanzar una excepción informando del motivo. No hace mucho años, un usuario en una aplicación de escritorio no ponía el DNI corréctamente y se le avisaba de que su DNI no era correcto. Eran otros tiempos dónde primaba la sincronía: acción/evento -> respuesta. Es decir, dónde las validaciones se hacían de manera directa con el usuario. Los tiempos han cambiado, ahora tenemos frontend y backend, ahora a una acción/evento no le viene una respuesta inmediata. Hay muchas operaciones intermedias. También hay muchos intermediarios que no tienen ni idea del dominio del problema, ellos sólo toman los datos de un lado para llevarlos a su destino.

No sólo eso, antiguamente a una acción/evento le seguía una respuesta. Hoy día eso es impensable e insufrible. ¿ Te imaginas la siguiente situación: ?

 > Fallo en la clave.
 > [ usuario corrige la clave y le da al botón enviar ]
 > Fallo en el número de digitos del DNI.
 > [ usuario corrige el número de dígitos del DNI y le da al botón enviar ]
 > Fallo en la letra del DNI.
 > [ usuario corrige la letra y le da al botón enviar ].
 > Fallo en el número de teléfono.

Hoy es requerida que a una acción/evento le sigan multiples tareas y pueda haber multiples respuestas. Sí, con try catch es posible pero no es de la forma para lo que fue construido.

Además, las excepciones tienen sólo dos estados posibles: todo fue bien o error imperdonable. Antiguamente, si lanzabas un comando desde terminal y la aplicación te quería mostrar un aviso, te lo mandaba por la salida estándar de error. Si años más tarde, en una aplicación de escritorio, la aplicación te quería dar un aviso, podía usar la barra de estado. ¿ y ahora ?. ¿ Cómo avisas al usuario que la contraseña que ha entrado para su usuario es corrécta pero es débil ?. ¿ Y si no hay navegador por medio porque respondes vía servicio web ?. Lo mismo si le quieres proporcionar un dato informativo adicional, no negativo, a su operación. Ejemplo: su usuario ha sido creado corréctamente y su dirección tal y cual está dentro de nuestra zona A y se le enviará su pizza en 30minutos.

Por otro lado, eso que si hay error este sea imperdonable, produce el mismo efecto que los !important en CSS: Una vez que empiezas con ellos no puedes dejar de usarlos en todas partes. ¿ Qué quieres que tu CMS haga una inserción en la base de datos de cada visita que accede al sitio web ?. Ojito con no ponerle un catch, porque si el componente que usas para acceder a la base de datos lanza una excepción por lo que sea y tu código no lo sabía( porque es sólo un intermediario ) el usuario puede dejar de poder ver tu web y quizás hasta vea información sensible en forma de algo que él no conoce. Sí, ya, quizás para ti y para el que visita la web no sea tan importante que un registro no se guarde en la base de datos bajo ciertas circunstancias, pero las excepciones son así: o todo o nada.

Para Trasweb Framework he solucionado todo esto mediante una clase pila de errores basada en niveles( bueno, casi todo el framework es basado en niveles ). Con niveles me refiero a lo mismo que ocurre en un terminal bash cuando lanza un comando. Es decir, si se lanza un comando en bash este crea una nueva instancia de bash que encapsula ese comando. Si ese comando lanza otro comando, se crea otra subinstancia basada en el anterior para lanzar el nuevo comando. El primer nivel no sabe nada del tercero ni el tercero del primero. El primero espera una respuesta del segundo y el segundo del tercero. Luego, de manera aproximada y simplificada, cada nivel tiene tres posibles estados primarios: ok, nok y system. Estos determinan si la operación que se solicitó se realizó bien(ok), no se realizó(nok) o hubo un fallo imperdonable( system ). A su vez hay dos posibles estados secundarios: info( para informaciones neutras ) y warning( para avisos de error en una operación intermedia ). Uno o más fallos warning suelen producir un nok. Por supuesto, todo ello de manera desacoplada. Sé que es difícil de visualizar sin código por medio pero ya quedará claro con la publicación de Trasweb Framework a lo largo de este año.

Cómo siempre digo, en diseño de software no hay nada ni bueno ni malo. Los GOTOs a veces son imprescindibles y por eso la mayoría de los lenguajes lo implmentan de una forma u otra. Las excepciones no son malas pero se hace un uso abusivo de ellas.

¡ Compártelo !
Este sitio utiliza cookies propias y de terceros para mejorar tu experiencia con el sitio web. Al continuar con la navegación consideramos que acepta su uso.