propagacion - tipos de excepciones en java

¿Es bueno atrapar un tipo más general de Excepción?

Question

Si vamos a atrapar formas específicas de IOException , o cualquier otro tipo como cuestión de hecho, y solo intentamos atrapar un par (y definir salidas definitivas para ellos) decir

FileNotFoundException
ZipException

deberíamos siempre seguirlo y cubrir todas las bases con un

catch(IOException e){
    e.printStackTrace();
}

y luego, posiblemente, ir aún más lejos y atrapar Exception e , ¿o es una completa pérdida de tiempo?

Answer 1

Capturar en blanco cualquier tipo de excepción no es una buena idea. Sí, como excepción para padres, parece proporcionar una capa de "protección", pero esto es malo por algunas razones:

IOExcepciones están marcadas. Si no hay ningún lugar en el código que lo arroje, agregar una captura innecesaria solo oscurece las cosas, y probablemente confundirá a cualquiera que mire el código más tarde.

Más importante aún, no se detectan excepciones para que desaparezcan. Si lo hicieran, podrías ajustar todos tus métodos en (catch (Exception e) {..}) y terminar con ellos. Su código de captura de excepción debe ser el lugar donde usted decide qué hacer si esos errores suceden, por ejemplo

catch(FileNotFoundException e)
{
 log.error("where''s the file?");return null;
}
catch(ZipException e)
{
 log.error("corrupt");return null;
}

El objetivo es hacer que el método se comporte bien en todas las condiciones posibles. La persona que llama luego se ocupa, por ejemplo, del contenido del archivo o del contenido, sin preocuparse por cómo llegó el contenido allí.

Answer 2

Como un buen consultor, digo "depende".

En general, en Java tiene una idea clara de cuáles podrían ser todas las posibles excepciones en un punto particular del código. No es raro ver a alguien usar

} catch (Exception e){
   // log or stack trace
}

... en más o menos código desechable. En general, sin embargo, no debería detectar una excepción que no sepa cómo manejar de manera útil. (Nunca, nunca, catch (Exception x) ; es decir, simplemente deseche la excepción. Nunca).

Lo dominante es preguntar "¿qué puedo hacer con esto?" A menudo, un archivo que no sea una excepción puede manejarse preguntando a un usuario dónde se ha ido su archivo. Una excepción de archivo zip es más difícil de manejar. Por lo tanto, es posible que desee tener comportamientos separados.

Por otro lado, si se trata de un programa de línea de comandos, es posible que desee nada más que un mensaje de error en cualquier caso.

Otro consejo más; no muestre un rastro de pila en el código "cutomer facing" - código que podría ver un no programador. Los no programadores tienden a mirar las complementaciones de un rastro de pila y pánico. Es mejor traducir la excepción a un mensaje como "Archivo ''nombre de archivo'' no encontrado". y, si realmente quiere un rastreo de pila, ose iniciar sesión para enviarlo a la salida de nivel de depuración.

Answer 3

Cuanto mayor sea la jerarquía de excepciones que está captando, y no manejando adecuadamente, o volviendo a lanzar, más problemas pondrá debajo de la alfombra. Puede tener errores silenciosos que son difíciles de rastrear.

Así que atrapa solo las Excepciones apropiadas, y deja pasar a los demás. En el nivel superior, puede tener una captura todo si no desea bloquear su programa, pero al menos iniciar sesión. Aún así, este es un enfoque cuestionable, porque su aplicación podría estar en un estado incoherente y puede dañar sus datos.

Pero para responder directamente a su pregunta, IOException podría estar en el nivel apropiado. Podría ser suficiente saber por ti que cualquiera sea el problema, se relaciona con IO, y puedes actuar de acuerdo con él. Es difícil de decir sin más información.

Answer 4

Depende si una excepción más específica ayudará en la resolución de problemas. A veces, al igual que con JMX, es bueno atrapar la excepción principal para evitar una larga lista de posible excepción infantil. Al menos Java 7 nos permitirá tener más de una excepción por captura. Eso limpiará el código bastante.

Answer 5

En caso de duda, siempre atrape la excepción más específica.

Answer 6

En general, solo debe capturar las excepciones que va a manejar de forma explícita.

No debería atrapar Exception, IOException, et. al., a menos que esté en un nivel apropiadamente alto en el que esté realizando su última revisión de zanja para informar un error general al usuario.

Answer 7

En general, solo desea capturar y manejar excepciones con las que puede hacer algo a un nivel bajo. Luego, en un nivel superior, atrape todo el sistema de excepciones no controladas, para que pueda registrar los errores que ocurrieron.

Answer 8

Haré un eco "capte la excepción más específica que pueda".

Capturo rutinariamente IOException y muestro algún tipo de mensaje de "error al leer el archivo", luego le permito al usuario seleccionar otro archivo o lo que sea apropiado. Si el archivo es realmente malo, probablemente no haya mucho que el usuario pueda hacer al respecto, pero al menos puede informarles que el archivo está dañado.

Si obtienes una excepción FileNotFoundException, el problema real es casi seguro que el usuario eliminó el nombre incorrecto del archivo o que el nombre del archivo codificado ya no es válido. De forma rutinaria mostrar mensajes para eso.

Casi nunca capturo "Excepción". ¿Qué vas a hacer al respecto? No hay mucho que pueda hacer para recuperarse de "algo salió mal pero no hay más detalles disponibles". En algunos contextos, supongo que al menos podría mostrar un mensaje de error en lugar de simplemente morir, pero eso es todo.

Answer 9

No debe detectarlos en todas las ubicaciones posibles donde puede ocurrir una IOException, pero más arriba en el árbol de llamadas donde está preparado para manejar las IOExcepciones restantes y las Excepciones generales.

Utilizamos la regla general, que detecta excepciones específicas en el lugar donde puede manejar el error y pasa las restantes a la persona que llama.

Answer 10

Creo que es una cuestión de preferencia personal. Personalmente, esta parece no ser una buena opción. Prefiero tener un código que tenga sentido para mí con las cosas de try-catch. Esto significa ser tan específico como sea posible. Yo diría:

try{
    //Code Here
}
catch(FileNotFoundException e){
    //Code Here
}