Estoy escribiendo algunas pruebas JUnit que verifican que se produce una excepción del tipo MyCustomException
. Sin embargo, esta excepción se envuelve en otras excepciones varias veces, p. en una InvocationTargetException, que a su vez está envuelto en una RuntimeException.¿Cuál es la mejor manera de verificar si un determinado tipo de excepción fue la causa (de una causa, etc.) de una excepción anidada?
¿Cuál es la mejor manera de determinar si MyCustomException de alguna manera causó la excepción que realmente capté? Me gustaría hacer algo como esto (ver subrayada):
try { doSomethingPotentiallyExceptional(); fail("Expected an exception."); } catch (RuntimeException e) { if (!e.
wasCausedBy(MyCustomException.class) fail("Expected a different kind of exception."); }
me gustaría evitar llamar getCause()
unos "capas" de profundidad, y similares feas soluciones temporales. ¿Hay una manera más agradable?
(Al parecer, la primavera ha NestedRuntimeException.contains(Class), que hace lo que quiero - pero no estoy usando la primavera.)
CERRADO: OK, supongo que no hay realmente ningún conseguir alrededor de un método de utilidad :-) Gracias a todos los que respondieron!
Tenga en cuenta que este algoritmo puede provocar un bucle infinito si la causa tiene un bucle, que puede ocurrir en algunos casos como las excepciones de EclipseLink DB. [Apache Commons Lang ExceptionUtils :: getRootCause] (https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/exception/ExceptionUtils.html#getRootCause (java. lang.Throwable)) maneja este caso, por lo que probablemente 'indexOfThrowable' de la respuesta de Patrick también lo haga. – DavidS
@DavidS No es un bucle infinito - lanzaría rápidamente 'StackOverflowError'. Si tienes un colapso de causalidad así, entonces tienes problemas más grandes (probablemente intentando reutilizar objetos de excepción aunque sean extrañamente mutables). –
A StackOverflowError, gracias. De todos modos, esto no es un problema con el código que he escrito; es un problema en algunas bibliotecas comunes, incluidos algunos controladores Oracle jdbc. Es un problema bastante común que Apache Commons decidió manejarlo en 'getRootCause', Oracle eligió manejarlo en [printStackTrace] (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962571), y Guava considerado manejarlo en [Throwables] (https://github.com/google/guava/issues/1173). Mi comentario fue para advertir sobre esto, no recomendar la mejor manera de construir Excepciones. – DavidS