Como se indica en ¿Qué tan lentas son las excepciones de Java? se puede ver que la lentitud of try {} catch {}
está dentro de la instancia de la excepción.
La creación de una excepción recuperará toda la pila de llamadas del tiempo de ejecución y aquí es donde está el gasto. Si no está creando una excepción, esto es solo muy un poco más de tiempo.
En el ejemplo dado en esta pregunta no hay excepciones, uno no esperaría que se produjera una ralentización al crearlas, no se crearon. En su lugar, lo que hay aquí es un try {} finally {}
para manejar la desasignación de recursos dentro del bloque finally.
Entonces, para responder a la pregunta, no, no hay un gasto de tiempo de ejecución real dentro de una estructura try {} finally {}
que no use excepciones (no es inaudito, como se ve). Lo que es posiblemente costoso es el tiempo de mantenimiento cuando uno lee el código y ve este no es el estilo de código típico y el programador tiene que tener en cuenta que algo más sucede en este método después de return
antes de regresar a la convocatoria anterior.
Como se ha mencionado, el mantenimiento es un argumento para ambas formas de hacer esto. Para que quede constancia, después de considerarlo, mi preferencia sería el enfoque final.
Considere el tiempo de mantenimiento de enseñarle a alguien una nueva estructura de lenguaje. Ver try {} finally {}
no es algo que uno ve a menudo en el código Java y, por lo tanto, puede ser confuso para las personas. Hay un tiempo de mantenimiento para aprender estructuras un poco más avanzadas en Java que lo que las personas están familiarizadas con ver.
El bloque finally {}
siempre se ejecuta. Y es por eso que debes usarlo. Considere también el tiempo de mantenimiento de la depuración del enfoque no final cuando alguien se olvida de incluir un cierre de sesión en el momento adecuado, o lo llama en el momento incorrecto, o se olvida de regresar / salir después de llamar para que se llame dos veces. Hay tantos errores posibles con esto que es imposible tener el uso de try {} finally {}
.
Al sopesar estos dos costos, es costoso en tiempo de mantenimiento no usar el enfoque try {} finally {}
. Si bien la gente puede dicker sobre cuántos milisegundos fraccionados o instrucciones jvm adicionales se compara el bloque try {} finally {}
con la otra versión, también se deben considerar las horas dedicadas a depurar la manera menos adecuada de abordar la desasignación de recursos.
Escriba el código que se puede mantener primero, y preferiblemente de una manera que evite que los errores se escriban más tarde.