Necesito una fuente autorizada de por qué no debes arrojar o atrapar java.lang.Exception

Question

Tengo una reunión de normas de codificación en poco más de una hora y necesito una respuesta rápida a esta.

La sabiduría común entre los programadores con experiencia de Java es que no arrojar o atrapar java.lang.Exception (con raras excepciones, sin juego de palabras). La razón por la que no lo hace es que la declaración

catch (java.lang.Exception ex) {...} 

también capturar las excepciones sin marcar, y en la mayoría de los casos esto no es lo que se pretende.

Ya tenemos una gran cantidad de código heredado escrito por los miembros del equipo existentes donde detectan una subclase de java.lang.Exception, registran un error y vuelven a lanzar la subclase como java.lang.Exception.

tengo que convencerlos de que

1. que necesitan para dejar de escribir código como este.
2. código existente que utiliza este anti-patrón tiene que ser fijo

número 2 significa una buena cantidad de refactorización.

Acortará el argumento en la reunión si puedo mostrar un artículo o entrada de blog por uno de los pesos pesados ​​de la comunidad Java que hace este punto (es decir, Joshua Bloch, James Gosling). Mi google-fu no ha encontrado nada hasta ahora.

¿Alguien sabe de un artículo o blog de un respetado gurú de Java que dice que no se debe lanzar o atrapar java.lang.Exception?

Las respuestas rápidas son muy apreciadas.

Dean

Answer 1

supongo que el punto es que si usted no sabe cómo manejar una excepción específica, entonces no debería cogerlo. Debería propagarse a un nivel superior con la esperanza de que pueda saber qué hacer con él. Capturar excepciones demasiado pronto lleva a que se traguen excepciones en silencio y hace que sea imposible hacer algo útil con ellas más allá del registro.

Imagínese lo que sucedería si el constructor de FileInputStream fuera a registrar una excepción internamente si intentó abrir un archivo que no existía, pero no indicó este error en su código. Está bien que el error se registre, pero su código desea detectar esta excepción y hacer algo útil con ella (como solicitar al usuario un nuevo nombre de archivo). Si fueran catch (Exception), no podrías hacer esto.

Answer 2

Si tiene a mano una copia de Effective Java de Josh Bloch, sé que cubre el manejo de excepciones con bastante detalle allí. No tengo acceso a él en este momento, así que no puedo resumirlo ni darle referencias de página, pero estoy bastante seguro de que tiene algunos buenos argumentos para no detectar java.lang.Exception.

Answer 3

Aquí está Bruce Eckel's viewpoint on checked exceptions in general, que es que en la mayoría de los casos son una mala idea. Tal vez eso tendrá algo que puedas usar.

Answer 4

No hay puntos en común aquí.Se encuentran dos grupos:

1. Los que odian excepciones comprobadas se captura y se envuelven en una RuntimeException de algún tipo.

2. Los que odian RuntimeException

El primer grupo odia al enigma de su código con try...catch, sobre todo porque en la mayoría de los casos, no se puede controlar la excepción cuando se ve por primera vez. Piense en IOException: podría arrojarse por cada byte que leyó. ¿Cuál es el código de bajo nivel que se debe hacer al respecto? Tiene que volver a lanzarlo para que alguien más arriba pueda agregar algún contexto útil al error (como qué archivo estaba leyendo).

El otro grupo quiere ver qué podría salir mal. RuntimeException efectivamente oculta esto.

Hay una solución simple, por cierto: Make Exception extend RuntimException. ¿Insano? Realmente no. Si haces eso con JDK 7, obtienes dos errores de compilación.

El siguiente paso sería hacer que todos los compiladores de Java enumeren todas las excepciones de tiempo de ejecución y enumerarlas en la entrada throws en el archivo de clase. Todavía no tiene que atraparlos, pero ahora, sabrá cuáles podrían suceder.

Por último, extienda los IDEs para mostrar esto. Y listo, ambos grupos podrían ser felices. Lamentablemente, esto no sucederá.

Answer 5

Aquí hay algo: Java Tip 134: When catching exceptions, don't cast your net too wide (JavaWorld)

Effective Java (Segunda edición) por Joshua Bloch podría tener algo de esto en el capítulo 9 (Excepciones), aunque no pude encontrar rápidamente cualquier cosa sobre la captura no Exception.

Aquí es a Q&A from JavaWorld sobre la cuestión (también apunta a Java Tip 134) - que también explica por qué a veces hay que romper la regla de no coger Exception o incluso Throwable.

Answer 6

Ver this article de Brian Goetz (el asistente de concurrencia) que tiene su propia visión, así como citar Josh Bloch en Java eficaz

Answer 7

donde se captura una subclase de java.lang.Exception, registrar un error, y vuelva a lanzar la subclase como java.lang.Exception. Necesito convencerlos de que deben dejar de escribir código como este.

Acepto que deben usar otra táctica, pero por diferentes razones. No tiene mucho sentido capturar una excepción solo para iniciar sesión y volver a lanzarla.

Una alternativa es: no capte la excepción y deje que un código más alto (como un filtro Java EE, o intente/capture su método main) capture y registre todas las excepciones no detectadas. Luego, se asegura de que cada excepción se registre solo una vez y sepa que se registrarán todas las excepciones no detectadas.

Si necesita agregar información adicional a la excepción, recójala, cambie el mensaje y vuelva a lanzarlo.Yo suelo usar una RuntimeException para esto:

} catch (Exception originalException) { 
    throw new RuntimeException("user name was " + userName, originalException); 
} 

Answer 8

es un artículo largo, pero this le propone:

1. uso comprobado excepciones cuando el cliente espera que este error que se produzca con regularidad y debe manejar la situación (por ejemplo: el usuario -entered datos no pasaron la validación)
2. uso de excepciones sin marcar, para condiciones inesperadas (por ejemplo: servidor de base de datos fue abajo)

En teoría, # 1 (exp Los errores rechazados deberían tener su propio tipo de excepción, y el único lugar que debería capturar un # 2 (una RuntimeException) es algún tipo de controlador de nivel superior que capte la excepción, lo registre y muestre al usuario un mensaje de error, e incluso aquí, probablemente deberías atrapar a Throwable para asegurarte de que se manejan las excepciones no detectadas.

Siguiendo estas pautas, no debe detectar Exception ya que no cumple con ninguno de los criterios anteriores (es decir, no es una RuntimeException y no es una subcasta de excepción especializada para indicar un error esperado).

Answer 9

Aquí está una muy insightful article

Resumen:

1. Uso excepciones comprobadas por contingencias raros pero válidos que se relacionan con el propósito de su código. El código del cliente debe saber cómo manejarlos.

2. Utilice las excepciones no marcadas para las fallas que no deberían suceder pero sí. (Servidor inactivo, classpath mal configurado, error de sintaxis SQL, etc.) El técnico de TI que administra el servidor o el desarrollador que acaba de pasar el SQL incorrecto a prepareStatement() debería saber cómo solucionar estos problemas. Las fallas deberían propagarse hasta la capa de registro para que la información no se pierda.