Errores comunes en el manejo de excepciones

Una excepción es una interrupción del flujo normal de ejecución de un programa Java (o cualquier otro). Esta infracción puede ocurrir debido a una infracción de acceso a la memoria, división por cero, problema de inicialización, ejecución de una instrucción ilegal o cualquier otro error fatal. Java es capaz de manejar con elegancia todos estos escenarios no deseados, pero cuando los desarrolladores utilizan estas funciones de Java, pueden surgir varios problemas. En este artículo, no voy a discutir cómo funciona el manejo de excepciones en Java. Supongo que el lector ya está familiarizado con la jerarquía de excepciones, excepciones marcadas , excepciones no marcadas y excepciones de tiempo de ejecución . Aquí te comentaremos los errores más comunes que debes evitar.

Partes interesadas en las excepciones

Siempre que se interrumpa el hilo de ejecución, la información sobre el mismo debe devolverse al ejecutor del programa. Este hilo puede comenzar desde la pantalla, desde una tarea por lotes o de cualquier otra forma. Todos estos desencadenantes esperan algún tipo de infracción en el flujo para transmitir un mensaje de cierto formato. Un disparador basado en pantalla puede informarnos suavemente que hay algunos problemas técnicos y que debemos comunicarnos con el soporte para obtener ayuda y asesoramiento. Los procesos por lotes o los programas Java independientes pueden esperar que el informe de error aparezca en forma de algún tipo de registro que sea completamente incomprensible para el usuario final. Pero los empresarios necesitan recibir mensajes en un idioma que comprendan. La temida NullPointerException en la mente de los usuarios es muy molesta. En ocasiones estos errores son consecuencia de un uso incorrecto del programa, pero en otras ocasiones son problemas que requieren corrección. El segundo actor importante es la persona que tendrá que abordar los problemas que plantean las excepciones. Esta persona no puede observar la ejecución real del programa cuando ocurre la excepción. Dependerá de dos cosas: en primer lugar, la información proporcionada por el usuario que tiene el problema y, en segundo lugar, algún tipo de registro generado cuando se produce una excepción. Además, la persona que analizará el problema no es la misma que escribió el programa y, por tanto, el desarrollador del programa debe proporcionar suficiente información para el análisis. La única forma de comunicación entre el desarrollador del programa y su depurador es un registro. Además, a veces, debido a razones de seguridad, es posible que el registro de registro no contenga todos los detalles reales de la ejecución del programa cuando ocurrió la excepción. Veamos posibles errores en el manejo de excepciones. Algunos parecen bastante estúpidos, pero hay gente. que no les prestan atención hasta que estos errores generan problemas.

Bloque de excepción vacío

Este es uno de los errores más no deseados en el manejo de excepciones. En este caso, la excepción simplemente se ignora. La solución no contiene nada más que una línea de comentario para dejar la excepción. try{ }catch(SQLException sqe){ // do nothing } En algunos casos raros, como en el bloque final cuando se cierra la base de datos, se pueden generar excepciones. En este caso se pueden ignorar. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Generalización incorrecta del mensaje de excepción.

Este punto es subjetivo. Después de detectar la excepción, puede informarla al usuario final en forma de mensaje amigable. Es muy posible que los detalles del mensaje original se pierdan cuando los mensajes originales se conviertan en un mensaje general. El mensaje debe transmitir la información adecuada al usuario final, de modo que cuando se comunique con el equipo de soporte, el usuario solo necesite iniciar sesión en el registro apropiado para proporcionar la información. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } En una aplicación de varios niveles, cada capa detecta excepciones y genera un nuevo tipo de excepción. A veces es absolutamente necesario lanzar una excepción de cierto tipo: - Capa de acceso a datos -> crea una DataAccessException - Capa de implementación empresarial -> crea una BusinessException - Capa de servicio de aplicaciones -> crea una ApplicationServiceException Todo parece lógico, ¿no? Aquí es posible que tengamos que elegir entre ApplicationServiceException y BusinessException ya que ambas pueden representar la misma información. Una de estas conversiones de excepción parece innecesaria.

Destruyendo la clase StackTrace

Durante el proceso de transformación de una excepción en un nuevo tipo especial, el seguimiento de la pila puede desaparecer, lo que hace que rastrear la causa real de la excepción sea una pesadilla. En el código siguiente puedes ver cómo se lanza una nueva excepción sin recibir ninguna información de la excepción original. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Sobrescribir el motivo de la excepción

Cada mensaje de excepción contiene información sobre el motivo de la excepción. Sin embargo, cuando se crea una nueva excepción, es posible que la información sobre la anterior se elimine permanentemente. Esto es similar al ejemplo anterior donde StackTrace puede eliminarse debido a que se lanza una nueva excepción.

No buscar excepciones específicas

A veces a los desarrolladores les gusta ir a lo seguro al manejar excepciones. A veces esto es fácil de hacer. Pero no es aceptable detectar java.lang.Exception en lugar de una excepción específica. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Atrapar y lanzar innecesariamente

Capture excepciones si desea convertirlas a otro tipo, o si le ayuda a agregar alguna información al mensaje de excepción para el usuario final o analista. De lo contrario, simplemente deséchelos más en la firma del método (usando lanzamientos) en lugar de capturarlos.

Capturando RuntimeException

Recomendaría evitar detectar RuntimeException. En cambio, es mejor detectar excepciones específicas y tratarlas.

Encontrar excepciones no comprobadas

Es un tema controvertido si se deben detectar excepciones no controladas o no. NullPointerException y ArrayIndexOutOfBound podrían ser los mejores ejemplos de excepciones no comprobadas. En lugar de detectar estas excepciones, puede cambiar su código para manejar estos escenarios. Por ejemplo, para evitar NullPointerException, para garantizar que todas las variables se inicialicen, para evitar excepciones ArrayIndexOutOfBound, para definir una matriz de la longitud correcta, etc.

Problemas relacionados con el registro de excepciones

La revista ayudará a la segunda persona interesada, es decir, a la que analiza el problema. A veces, un desarrollador se excede con los archivos de registro y se crean registros en todos los niveles de la aplicación. El registro debe registrar la excepción en el nivel en el que ocurrió. Parece óptimo mostrar una advertencia de que se ha producido una excepción, con una propuesta para detener o continuar la ejecución del programa y un registro obligatorio de la excepción en el registro.

Excepción de control de flujo

Una excepción es una interrupción del flujo normal del programa, lo que significa que es necesario interrumpir este flujo e informar al usuario final al respecto. Si agregamos una llamada a un método que sea un hilo alternativo, generará enormes problemas de mantenimiento. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Uso ubicuo de java.lang.Exception

Tampoco es una buena idea utilizar java.lang.Exception en todas partes para cualquier excepción. En su lugar, es mejor utilizar excepciones específicas de la aplicación o las excepciones estándar de Java más apropiadas. Artículo original: Errores comunes en el manejo de excepciones Traducido y expresado por: Ve4niY