Unicode y Excepciones: Un buen artículo y un mal comentario
El siempre brillante Joel Spolsky ha escrito un gran artículo sobre los juegos de caracteres de las cadenas en programación y una explicación sencilla sobre Unicode: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!). Realmente imprescindible para cualquier programador.
El no siempre tan brillante Joel Spolsky dice no entender y desaprobar la programación con excepciones. Lo que yo no puedo entender es cómo alguien puede trabajar sin ellas. Realmente el uso de excepciones simplifica enormemente el trabajo de programación sin introducir ninguno de los defectos que el cree verles. Permite escribir por un lado el flujo normal de un método o función y por otro lado la gestión de errores que se pueden dar. Sobre su lista de defectos se puede comentar (por lo menos en lo referido a Java):
- No son invisibles en el código fuente. Por lo menos en Java la lista de excepciones que un método lanza están declaradas en la propia definición del método y de hecho obliga a pensar qué hacer en caso de error (capturar el error para solucionarlo o pasar la excepción un nivel arriba si no se tiene información suficiente para solucionarlo).
- No crean demasiados puntos de salida para una función. De hecho, sólo es así si la excepción no se captura y aún en ese caso se tiene la oportunidad de limpiar el estado de variables y recursos en la clausula finally.
En fin, que cualquier práctica de programación puede usarse mal, pero las excepciones tienen la potencialidad de simplificar el trabajo del programador y asegurar programas más robustos.
Sigo desde hace años los artículos de Joel Spolsky, y me ha sorprendido bastante este último.
Encima la solución/alternativa que propone, me parece un poco "arcaica", tener que comprobar constantemente que devuelven las funciones... :(
Yo programo con Delphi, y cuando descubrí el poder de las excepciones me dije: "¿Pero como he podido programar si esto...?"
A mi las excepciones me recuerdan, en cierto modo, al ON ERROR del Clipper y del BASIC, es decir, cuando se produce un error a que se llama, pero con la ventaja que no has de tener un manejador global y universal de errores, sino que puedes adaptar el manejo/solución del error a cada caso.
Y de la forma que propone el tema de utilizar los valores de retorno de una función para verificar si todo ha ido bien... Que hacemos cuando una función de una librería me lanza una excepción, ¿no la capturo? ¿Dejo que me "rompa" el flujo de mi programa?
En los entornos actuales de desarrollo todo funciona por eventos y por objetos, que mejor técnica que las excepciones (que no dejan de ser una especie de evento) para estos lenguajes.
Una cosa es verdad... Que a veces una excepción excepcional (valga la "rebuznancia") provoca una cascada de excepciones, pero eso más que fallo de las excepciones es fallo del programador, porque simplemente no ha puesto un "capturador" para dicha excepción. Es como decir que cuchillos son malos porque con ellos puedes matar a personas, no son los cuchillos es el mal uso que se hace de ellos, como muy bien dices al final del post.
me ha parecido muy interesante tu articulo.
Desgraciadamente, en la actualidad, se desarrollan aplicaciones mas complejas pero sin darle demasiada importancia a las excepciones.
Hay aplicaciones en las que cualquier excepcion producida puede ser un desastre, como en aplicaiones que esten en juego vidas humanas.
Al desarrollar aplicaciones nos centramos sobretodo en el desarrollo para el comportamiento normal, dejando las excepciones en otro lugar.
Si se tienen en cuenta las excepciones a un nivel mas avanzado, se suele aumentar el codigo considerablemente, no siendo una tarea sencilla.
Si, la gestion de excepciones que proporciona java, si se pasa un poco por alto la profundidad de las excepciones, puede ayudar mucho a desarrollar aplicaciones sin tener tan en cuenta estas excepciones. Pero si se quiere realizar una gestion de excepciones mas minuciosa puede no ayudar tanto, y puede reflejarse en el aumento excesivo de codigo.
1/ Si quieres puedes poner el código de lo que ocurre cuando todo funciona bien, poner ese código alrededor de un try/catch y poner ahí la gestión de errores. Yo creo que esta es la forma de trabajar y es algo que se puede hacer con excepciones pero no con un control de errores por código devuelto. O bien...
2/ Puedes querer realizar una gestión minuciosa del error que te devuelve CADA función (yo no creo que esta sea la forma, pero entiendo que quieras hacerlo).
En ese caso vía códigos de error harías en cada línea:
int i=open(fichero);
if (i==-1) {
// Error de fichero no encontrado
}
Mientras que con excepciones harías:
try { File f=open(fichero); }
catch (FileNotFound e) {
// Error de fichero no encontrado
}
¿Dónde está el aumento de código? Lo que quiero decir es que si quieres controlar CADA error con su propia gestión, es evidente que aumenta excesivamente el código, pero eso es así lo hagas con excepciones o sin excepciones. Lo bueno de las excepciones es precisamente que te permiten tener un buen control de los errores sin complicar excesivamente el código.
Un saludo.
En la mayoria de las aplicaciones no es necesario realizar una gestión de excepciones muy municiosa. En este caso la solución que proporciona Java con respecto a las excepciones es estupenda ya que permite diferenciar claramente el comportamiento normal del comportamiento excepcional de la aplicación. En este caso estoy totalmente de acuerdo contigo.
Ahora bien, si se requiere una gestión de excepciones mas exaustiva pues el código aumenta excesivamente y el mecanismo de excepciones que proporciona Java en vez de ayudar puede incluso ser un problema de cara al mantenimiento posterior de la aplicación. Te pongo varios ejemplos:
Ejemplo de gestión de excepciones no rigurosa, teniendo en cuenta que todas las funciones pueden lanzar las excepciones Error1, Error2 y Error3:
try{
Funcion1(...);
Funcion2(...);
Funcion3(...);
}catch(Error1 e){
//Tratamiento del Error1
}catch(Error2 e){
//Tratamiento del Error2
}catch(Error2 e){
//Tratamiento del Error3
}
En este caso estoy totalmente de acuerdo contigo.
Ahora bien, si se tiene una aplicación critica en el que la producción de una excepción es muy perjudicial en la aplicación, se puede obtener el siguiente resultado del ejemplo anterior:
try{
Funcion1();
try{
Funcion2();
Funcion3();
}catch(Error2 e){
//Tratamiento1
//Tratamiento2
//...
}catch(Error3 e){
//Tratamiento1
//Tratamiento2
...
}catch(Error1 e){
//Tratamiento1
//Tratamiento2
...
}catch(Error2 e){
//Tratamiento1
//Tratamiento2
...
}catch(Error3 e){
//Tratamiento1
//Tratamiento2
...
}
Es por ponerte un ejemplo, por que se puede complicar aun mas la gestión de excepciones (lo se por experiencia). En este ultimo ejemplo, la cantidad de lineas de código dedicadas a los bloques try/catch es excesivo (y eso que no he utilizado el bloque finally). Incluso aunque se utilice la jerarquia de excepciones capturando y tratando solamente las excepciones mas generales, pasando de las excepciones derivadas.
Se que es excesivo la minuciosidad de la que estoy hablando, pero hay veces que no hay mas remedio.
Un saludo.
Jose Maria.
Comentarios cerrados para este artículo