¿Alguna vez ha visto un archivo Java close() arrojar una excepción?

Question

¿Alguien ha visto alguna vez una excepción al invocar el método Cerrar en cualquier objeto que se pueda cerrar?

Answer 1

Se lanzará IOException en close si falla el flush final. Las posibles causas incluyen:

• el sistema de archivos está lleno, o si el usuario ha terminado de cuotas,
• errores de disco duro,
• un sistema de archivos era la fuerza sin montar,
• un sistema de archivos remoto no está disponible debido a redes u otros problemas,
• (posiblemente) una codificación de caracteres de error si escribir en el archivo a través de un OutputStreamWriter o similares,
• un error de dispositivo si el "archivo" es un archivo de dispositivo,
• una conexión perdida si el cerrable es una corriente de red,
• una tubería rota si el cerrable es un tubo de proceso externo,
• y así sucesivamente.

Ciertamente he visto algunos de estos. Otros son poco probables.

Sin embargo, si los datos que está escribiendo son importantes, debe permitir que close fallen. Por ejemplo, si su aplicación está escribiendo un archivo crítico, el sistema de archivos se llena, su aplicación debería notar esto antes de reemplazar la copia anterior del archivo con la versión truncada.

Answer 2

Supongo que podría intentar forzar esto desenchufando el disco en el que está su archivo. Pero en cualquier Closable? Creo que sería fácil obtener algo que use un socket para lanzar una excepción al cerrar.

Answer 3

No lo he hecho, pero es posible. Imagínese si hay un OutputStream que por algún motivo aún no ha escrito en el archivo. Bueno, al llamar al close() se eliminarán los datos, pero si el archivo está bloqueado, se generará un IOException.

Answer 4

Sí, no es tan raro, en mi humilde opinión si está trabajando con algo que no sean archivos de disco no locales.

Cerrar() funciona si en ese momento su cierre sigue siendo válido y abierto. Muchas cosas como tuberías, archivos remotos, etc., pueden morir prematuramente.

Además, he visto un código que ignora los errores al abrir y escribir y todavía intenta cerrarse (por ejemplo, en un bloque finally).

Answer 5

No en términos de archivo-io, pero en términos de sockets, el cierre aumentará IOException cuando el otro lado haya abortado la conexión. Por ejemplo, cuando lanza una solicitud HTTP en una página web (grande) y luego navega de inmediato haciendo clic en otro enlace en la página web (mientras no se termina de cargar), el lado del servidor obtendrá un IOException (o una subclase similar) ClientAbortException en servidores y clones de Tomcat) cuando el flujo de salida de la respuesta HTTP se va a enjuagar/cerrar.

Answer 6

que tienen - en mis pruebas unitarias contra burla;)

Answer 7

Trate tirando de una unidad USB con un archivo abierto en él. Si no da una excepción, estaría bastante sorprendido.

Answer 8

Mensaje viejo y desde hace mucho tiempo contestado pero aquí es un ejemplo real:

El siguiente código excepto cuando se llama bufferedWriter.close(). Esto sucede porque el Escritor subyacente de BufferedWriter (el FileWriter) ya se ha cerrado y cuando un BufferedWriter se cierra, primero intenta vaciar cualquier información en su búfer a su Writer subyacente.

File newFile = new File("newFile.txt"); 

FileWriter fileWriter = new FileWriter(newFile); 
BufferedWriter bufferedWriter = new BufferedWriter(fileWriter); 

bufferedWriter.write("Hello World"); 

fileWriter.close(); 
bufferedWriter.close(); 

Nota: Si no hay datos en el búfer [comentario la línea de escritura() o añadir una llamada a flush()] entonces no es una excepción, se generará