2010-07-29 6 views
8

¿Hay alguna manera de diferenciar programáticamente entre lo que causó una IOException? Por ejemplo java arrojará una IOException, si hubo un error durante la escritura. ¿Cómo puedo saber si hay algo así como violación de acceso, si el disco está sin espacio libre, si alguien desconectó la unidad de red u otras cosas?¿Determinando de forma programática la causa de IOException?

No puedo realmente analizar el Mensaje ya que no parece haber ningún formato de mensaje estandarizado, Sun (u oráculo ahora supongo) no parece tener ningún tipo de formato estandarizado.

Cualquier sugerencia (soy bastante nuevo en Java, no es mi lenguaje normal, pero hay que usarla para fijar un sistema muy rota en el trabajo.)

Respuesta

5

Desafortunadamente Java no tiene un equivalente de .NET de System.Runtime.InteropServices.Marshal.GetHRForException(). Dice qué tipo de error de E/S fue solo si la excepción es una instancia de una subclase, p. FileNotFoundException.

+0

Puede que no sea lo que quería escuchar = (pero me contestó. – UberJumper

0

Obtener la clase exacta de la excepción le dará una de las pocas posibles subclases de IOException, y estas son bastante estandarizadas. Puede probar las clases con instanceof o (un enfoque brutal) comparar cadenas devueltas desde getClass().getName().

Hay algunas soluciones para las otras cosas; puede hacer un File.canWrite() en un archivo que está a punto de abrir para escribir (bueno, su programa debería haber hecho eso de todos modos, si el nombre y/o el directorio pueden variar), y si hay una posibilidad de que se quede sin espacio en el archivo, podrías intentar escribir un archivo pequeño en una buena ubicación conocida y ver si explota en ti. No muy elegante, lo sé: Java no es realmente conocido como un lenguaje de programación de sistemas.

Por otro lado, muy a menudo saber una causa detallada de una excepción no ayuda mucho: con o sin el conocimiento, su usuario puede simplemente no ser capaz de hacer que el programa haga lo necesario.

+3

Una posible adición a su primer párrafo; generalmente está 'atrapando' estas excepciones, por lo que una alternativa más agradable es tener capturas separadas bloques para 'FileNotFoundException',' UnknownHostException', etc. Evita las pruebas "explícitas" y le permite manejar los casos especiales en diferentes bloques desde el comienzo (sin excluir un bloque catch 'all catch (IOException e)' al final) –

+0

@Ahdrzej: Tiene mucha razón. Estaba pensando en correcciones de band-aid a la codificación preexistente y asumiendo que uberjumper no quería reorganizar las jerarquías de captura existentes (lo que sea que haya). Pero si "doing es correcto "es una opción, entonces tu camino sería. –

Cuestiones relacionadas