Refactor la gestión de excepciones

Question

Ok he pecado, he escrito mucho código como este

try { 
    // my code 
} catch (Exception ex) { 
    // doesn't matter 
} 

Ahora voy a la limpieza/refactor esto.

Estoy usando NB 6.7 y la finalización del código funciona bien en la primera escritura, agregando todos los tipos de excepción, etc. Una vez que he hecho el código anterior, NB no da más ayuda.

¿Conoces alguna manera de decir NB que busque nuevamente todos los tipos de excepción y hacer la propuesta para manejarlos y completar el código nuevamente?

Answer 1

Cuando pide una propuesta sobre cómo manejar las excepciones ...

No hay forma generalmente aceptada para manejarlos. De lo contrario, puedes apostar que el lenguaje Java tendría implícitamente ese comportamiento.

• Las excepciones no son una restricción de bajo nivel que uno debe enfrentar hasta que el compilador sea lo suficientemente inteligente.
• Las excepciones son un constructo de lenguaje de alto nivel, utilizado para expresar la semántica "sucedió algo excepcional, cuyo tratamiento no desea mezclar con el código normal; prefiere que se maneje en códigos específicos". Existen

---

excepciones en dos formas, por diseño:

• excepciones comprobadas deben hacerse explícitos en cada método que puede tirarlos.
• Las excepciones no comprobadas (subclases de RuntimeException o Error) suelen ser implícitas.

En cada nivel de código (método o bloque), el código tiene que elegir qué hacer, en el caso de alguna excepción (excepto excepciones no marcadas que pueden omitir el tratamiento por completo). Esta es una selección de responsabilidad que varía, no hay una decisión válida para todos los casos:

• PROCESO: La captura y procesar por completo (llamando a los códigos no suelen saber algo sucedido). El método actual necesita tener la responsabilidad. Registrar el seguimiento de la pila para el desarrollador puede ser útil.
• PASO: Atrápelo, haga un paso del procesamiento que está relacionado con el código local, y vuelva a lanzarlo (o vuelva a lanzar otra excepción con la original como causa).
• IGNORE: simplemente déjela bajo la responsabilidad del código de llamada.

el lenguaje Java le permite disponer de sintaxis específicos haciendo más fácil de manejar excepciones, como la captura de excepciones específicas seguido los más generales ...

---

Por lo general, se tiene en cuenta excepciones en su arquitectura, y tomar algunas decisiones de diseño Algunos ejemplos (mezclados de una forma única):

• optar por tener un proceso de capa de todas las excepciones producidas en las capas inferiores (por ejemplo: servicios transaccionales): el registro para el revelador, posicionamiento alguna información global para el usuario ...
• deje que algunas excepciones suban algunas llamadas al método hasta que llegue a un código donde sea significativo procesarlo (por ejemplo, dependiendo de sus excepciones, puede volver a intentar una operación completa o notificar al usuario ...)
• etc.

Answer 2

El problema es que su controlador catch-all "maneja" todas las excepciones, por lo que no es necesario que Netbeans muestre más pistas.

Si sus manejadores de excepciones ya están vacíos y planea refaccionarlos de todos modos, puede simplemente eliminarlos temporalmente.

Consejo: Formatee automáticamente su código, busque try y use el resaltado del paréntesis para encontrar los bloques catch coincidentes. A continuación, elimine todo el código de manejo.

Después de esto, Netbeans volverá a proponer varias acciones para manejar las posibles excepciones.

PD: Tenga cuidado, el manejo predeterminado de Netbeans (es decir, simplemente el registro) no siempre es la mejor opción.

Answer 3

que sólo puede proporcionar el enfoque del eclipse y la esperanza de que es algo similar con NetBeans:

1. quitar las declaraciones try/catch -> Eclipse mostrará los errores de compilación
consejo rápido
2. uso de Eclipse para refactorizar la correcta instrucciones try/catch (o throw)

Puede guardar su código de manejo de excepciones existente para pegarlo después de la refactorización.

Editar

Tom tenía un muy buen comentario acerca de RuntimeException. Por lo que el procedimiento debe mejorar este aspecto:

1. copia de la cláusula catch existente y pegar a un editor de la libreta/de texto
2. quitar las declaraciones try/catch -> Eclipse mostrará los errores de compilación
3. uso de rápida Eclipse punta refactorizar la correcta try/catch (o tirar) declaraciones
4. pegar la cláusula catch almacenada al final de la secuencia de declaraciones de capturas

Esto conservará el control de excepciones de tiempo de ejecución Excepciones (¡y subtipos!).

Así que desde

try { 
    Integer.parseInt("Force a RuntimeException"); 
    myInputStream.close(); 
} catch (Exception oops) { 
    // catch both IOException and NumberFormatException 
} 

que vaya a

try { 
    Integer.parseInt("Force a RuntimeException"); 
    myInputStream.close(); 
} catch (IOException oops) { 
    // catch IOException 
} catch (Exception oops) { 
    // catch NumberFormatException 
} 

(aunque se podría reemplazar manualmente Excepción por NumberFormatException en este caso, pero es sólo un ejemplo)

Answer 4

PMD identifica todos estos lugares donde tiene catch bloques vacíos (PMD hace mucho más en realidad). Tiene integración con NetBeans, así que pruébalo.

Después de identificar todos los lugares vacíos con bloques catch tendrá que considerar cada uno por sí mismo:

• veces sólo registrar el mensaje
• veces reestructurar código de cerca. Es decir. Si está capturando un NullPointerException, agregue un cheque null en su lugar.
• a veces tendrá que considerar excepciones de reintroducción (y declarar verificadas).