¡Java entra en vigencia el martes! Pruebe los recursos primero

Hoy, tenemos un tema que es exactamente el mismo que discutimos la semana pasada. La semana pasada, el tema fue agentes de estilo y limpieza. Uno de estos usos comunes es limpiar recursos. En esta publicación de blog, detallaremos los mejores métodos insinuados al final de la publicación anterior.

Por varias razones, hay muchos recursos que deben cerrarse manualmente después de su uso. Esto generalmente se hace mediante el uso del método off en el objeto. Por supuesto, no queremos filtrar recursos o dejar elementos en un estado medio controlado. En este caso, podemos considerar colocar el método off en un último bloque. Por ejemplo:

static List<Object> getDbValues() {
  EntityManager em = getEntityManager();
  try {
    return em.createNativeQuery("SELECT * FROM myTable").getResultsList();
  } finally {
    em.close();
  }
}

Eso es todo, se ve bastante bien. A medida que agregamos más recursos, se vuelve más confuso y propenso a errores.

static List<Object> getDbValues() {
  OutputStream output = getOutputStream();
  InputStream input = getInputstream();
  try {
    try {
      // do work
    } finally {
      input.close();
    }
  } finally {
    output.close();
  }
}

Esto comenzó a volverse más duro y difícil de seguir. ¿Lo estoy haciendo bien? No lo creo Es fácil equivocarse. El autor incluso admite que este patrón se ha estropeado en uno de sus libros a lo largo de los años, y nadie se dio cuenta. Incluso con el código correcto, las sutilezas del manejo de errores no se pueden manejar bien. Las excepciones pueden sobrescribirse entre sí, y podemos perder información valiosa en el seguimiento de la pila que ocurrió. Puede escribir código para tratar este problema, pero es complejo y feo, por lo que nadie puede escribir eso.

Por lo tanto, en Java 7, obtuvimos una mejor respuesta, pruebe los recursos. Con esta construcción, cualquier clase que implemente el apagado automático puede manejar su apagado en Java. Entonces el ejemplo anterior se ve así:

try(InputStream input = new FileInputStream("file");
    OutputStream output = new FileOutputStream("other")) {
            // do work
}

Esto es mucho más simple. Maneja más que el ejemplo anterior. En realidad, esta no es una forma de mantener el código. El código anterior se traduce en resultados más detallados por el compilador. Echemos un vistazo:

InputStream input = new FileInputStream("file");
Throwable var2 = null;

try {
    OutputStream output = new FileOutputStream("other");
    Throwable var4 = null;

    try {
        //do work
    } catch (Throwable var27) {
        var4 = var27;
        throw var27;
    } finally {
        if (output != null) {
            if (var4 != null) {
                try {
                    output.close();
                } catch (Throwable var26) {
                    var4.addSuppressed(var26);
                }
            } else {
                output.close();
            }
        }

    }
} catch (Throwable var29) {
    var2 = var29;
    throw var29;
} finally {
    if (input != null) {
        if (var2 != null) {
            try {
                input.close();
            } catch (Throwable var25) {
                var2.addSuppressed(var25);
            }
        } else {
            input.close();
        }
    }

}

Wow! Eso se volvió muy intenso. Sin embargo, si lo analiza detenidamente, encontrará que está haciendo lo que queremos y puede manejar las excepciones más a fondo.

Pensamiento final. En una publicación anterior mencioné la herramienta Lombok . Creo que esta es una buena herramienta. Dentro de la bolsa de trucos de Lombok hay una anotación @Cleanup. Parece que hará algo muy similar a lo anterior. Entonces, ¿qué hace que estos dos sean diferentes? Si bien es cierto que hacen cosas similares, tienen un poco diferente. La principal diferencia es que @Cleanupsimplemente escribe las combinaciones de probar-finalmente como hicimos anteriormente, pero no hace ningún manejo mágico del manejo de excepciones. Entonces, si bien @Cleanupnos da la seguridad de un bloqueo finalmente perdemos el manejo especializado de excepciones.

Entonces lo tienes. Use probar con recursos. Más simple, limpio y seguro, este es un lugar donde no veo demasiadas deficiencias.

de: https://dev.to//kylec32/effective-java-tuesday-prefer-try-with-resources-2om9