org fileupload dependency dependencia commons closeshieldinputstream java apache-commons apache-commons-io

java - fileupload - ¿Es seguro usar Apache commons-io IOUtils.closeQuietly?



java io ioexception maven (4)

El código debería ser similar al javadoc de closeQuietly() :

BufferedWriter bw = null; try { bw = new BufferedWriter(new FileWriter("test.txt")); bw.write("test"); bw.flush(); // you can omit this if you don''t care about errors while flushing bw.close(); // you can omit this if you don''t care about errors while closing } catch (IOException e) { // error handling (e.g. on flushing) } finally { IOUtils.closeQuietly(bw); }

closeQuietly() no está destinado para uso general en lugar de llamar a close() directamente en un Closable. Su caso de uso previsto es para garantizar el cierre dentro de un bloque final: todo el manejo de errores que debe hacerse ANTES de eso.

Eso significa que, si desea reaccionar ante Excepciones durante la llamada de close() o flush() , debe manejarlo de la forma habitual. La adición de closeQuietly() en el bloque finally solo asegura el cierre, por ejemplo, cuando el flujo falló y no se llamó al cerrar en try-block.

Es este código

BufferedWriter bw = new BufferedWriter(new FileWriter("test.txt")); try { bw.write("test"); } finally { IOUtils.closeQuietly(bw); }

seguro o no? Por lo que entiendo cuando cerramos un BufferedWriter, vaciará su buffer a la secuencia subyacente y puede fallar debido a un error. Pero la API IOUtils.closeQuietly dice que cualquier excepción será ignorada.

¿Es posible que una pérdida de datos pase desapercibida debido a IOUtils.closeQuietly?


Es posible en teoría, pero no puedo decir que haya visto alguna vez close () fallar. Por lo general, la falla rápida significa que una operación de IO previa, como abrir el archivo, fallará primero. Puedes escribir un cierre que no ignore IOExceptions, pero esto podría dañar la verdadera causa de una excepción si es algo en el bloque try / catch que falló.

Lo que quiere es algo como lo siguiente (que es excesivo en la mayoría de los casos)

try { // write to bw. bw.close(); // throw IOException if an error occurs. } finally { // don''t clobber a previous IOException IOUtils.closeQuietly(bw); }


Es seguro siempre que a su aplicación no le importe si la escritura tuvo éxito sin error. Si su aplicación necesita gestionar los errores de escritura, no es seguro, ya que los datos almacenados temporalmente al abrirse pueden perderse y el error puede tragarse.


Sí, es seguro usarlo, pero solo para Java6 y versiones anteriores . Desde Java7 , debes try-with-resource .

Eliminará gran parte del código repetitivo que tiene y la necesidad de utilizar IOUtils.closeQuietly .

Ahora, tu ejemplo:

BufferedWriter bw = new BufferedWriter(new FileWriter("test.txt")); try { bw.write("test"); } finally { IOUtils.closeQuietly(bw); }

Se puede escribir como:

try (BufferedWriter bw = new BufferedWriter(new FileWriter("test.txt"))) { bw.write("test"); }

Es importante tener en cuenta que para usar el enfoque de intentar con recursos, su recurso necesita implementar una nueva interfaz llamada java.lang.AutoCloseable que se introdujo en Java 7.

Además, puede incluir una cantidad de recursos en un bloque try-with-resource, simplemente sepárelos ;

try ( BufferedWriter bw1 = new BufferedWriter(new FileWriter("test1.txt")); BufferedWriter bw2 = new BufferedWriter(new FileWriter("test2.txt")) ) { // Do something useful with those 2 buffers! } // bw1 and bw2 will be closed in any case