try tipos excepciones catch java exception-handling control-flow try-catch-finally

java - tipos - ¿Es esto `try..catch..finally` redundante?



try catch throw java (5)

public Foo doDangerousStuff() throws Exception { try { dangerousMethod(); return new Foo(); } catch (Exception e) { throw e; } finally { mustBeCalledAfterDangerousMethod(); } }

¿Se comporta de forma diferente que si omitiéramos la cláusula catch?

public Foo doDangerousStuff() throws Exception { try { dangerousMethod(); return new Foo(); } finally { mustBeCalledAfterDangerousMethod(); } }

[edit] Para despejar la confusión, sí, el bloque catch no hace nada, excepto volver a lanzar la excepción. Me preguntaba si esto causó algún tipo de ordenamiento diferente cuando se invoca el bloque finally (suponiendo que la excepción lanzada es captada por la persona que llama), pero por lo que infiero de las respuestas hasta ahora, no es así.


Aunque los dos códigos fuente representan la misma secuencia de ejecución, darán como resultado un bytecode diferente. La primera rutina tendrá una tabla de excepciones, por ejemplo, mientras que la segunda no. Su bytecode tendrá el mismo efecto durante la ejecución, en ausencia de instrumentación. Es posible que estos métodos se comporten de manera diferente si el bytecode se instrumenta después de la compilación o si la excepción detectada es de un tipo cuyo archivo de clase no está disponible durante la ejecución.


Como está lanzando la excepción, ha atrapado la cláusula de captura y no hace nada más que tirarla de nuevo, sí, ambos códigos harán lo mismo.


Ellos son lo mismo. Yo usaría la segunda versión.


Sí. Como su método ya arroja "Excepción", no necesita atraparlo y volver a lanzarlo. A menos que quieras hacer lo que @Dave mencionó.


Tienes razón, es lo mismo. Incluso la stacktrace estará allí :)

Pero un código similar puede ser útil si envuelve la excepción en algún nivel superior. Si el código se ve exactamente como se dijo, no tiene sentido.