Capturando varias excepciones y volviendo a lanzar una excepción general

Question

Estoy usando el reflejo para agregar algunos datos a una variable privada dentro de una clase de una biblioteca de terceros. En el camino hay alrededor de cuatro excepciones diferentes que pueden lanzarse; todos ellos están relacionados con la reflexión, y es muy poco probable que ocurran. Estoy codificando el nombre de la clase y la variable involucrada. Es poco probable que reciba ningún error de clase no encontrada o campo no encontrado, a menos que la biblioteca se actualice algún día y haya cambiado significativamente.

Prefiero no declarar las cuatro excepciones para que la identifique. Es probable que nunca los vea. Me gustaría simplemente capturar todos estos y lanzar otra excepción para decir "Se ha producido un error de reflexión de Java, es probable que la biblioteca se haya actualizado y cambiado de una manera incompatible con este método". ¿Hay una excepción estándar de Java que pueda arrojar que indique solo un error de reflexión general? ¿Debería definir el mío? ¿O sería mejor simplemente declarar que este método puede arrojar todas las posibles excepciones de reflexión?

Answer 1

Puede convertir todas las excepciones en un AssertionError si nunca espera que ocurran. InvocationTargetException se puede desenvolver si desea tratar con una excepción específica. Si desea emitir la excepción real lanzada por el método en lugar de InvocationTargetException puede utilizar este truco, pero puede ser más confuso que útil

} catch (InvocationTargetException e) { 
    // Throw any exception in the current thread (even if it is a checked exception) 
    Thread.currentThread().stop(e.getCause()); 
} 

Answer 2

lo general pregunto a mí mismo estas preguntas:

• ¿Puede quien llama a este método manejar estos diferentes tipos de excepción de manera diferente?
• ... ¿O los tratarían todos igual?
• ¿Puede la persona que llama/el usuario incluso recuperarse de este error?

Si es probable que el código de llamada trate las cuatro excepciones de la misma manera (como un error irrecuperable), tiene sentido capturar cada una de ellas y volver a lanzar una excepción más general (única). Si lo hace, asegúrese de adjuntar la excepción generada como una excepción interna, solo para ayudar con la depuración o solución de problemas en el otro extremo.

Answer 3

Existe cierta controversia acerca de las excepciones controladas frente a las no verificadas. Personalmente, creo que las excepciones comprobadas son la peor idea en Java, pero eso es solo una opinión (sin embargo, no estoy solo pensando en eso)

De todos modos, creo que lo importante sería cambiarlos a una sola excepción sin marcar . La mayoría de las veces utilizo una sola como IllegalStateException o IllegalParameterException: con una descripción de texto claro, esas dos excepciones cubren el 90% de la basura que puede salir mal con un método.

Answer 4

No creo que tenga sentido declarar excepciones en este caso. Así que captaría las excepciones de la reflexión, tal vez registraría un seguimiento de la pila, y lanzaría alguna RuntimeException, que tiene la ventaja de que no necesita ser declarada. Puede usar RuntimeException con un mensaje adecuado, si es flojo.

Answer 5

En primer lugar, no use el reflejo a menos que realmente, realmente tenga que hacerlo, porque es malo. Suponiendo que usted tiene que:

Como está codificando todos los nombres, simplemente deja Method.invoke, Constructor.newInstance y Field.get/set. Sugeriría que solo vuelvas a lanzar las excepciones marcadas que puedes tratar envueltas en Error. No deberían suceder, y si desea lidiar con ello, le sugiero que haga el control en el momento de la entrada en la clase. InvocationTargetException debería, por supuesto, desenvolverse y tratarse de manera apropiada (arroje un Error envuelto para la excepción marcada que el método/constructor no declaró).

Answer 6

¿Qué hay de tener esas clases de excepción se extendía desde un GeneralException y captura que esa GeneralException?

¡Intentaré esto ahora mismo! :)