2010-02-09 10 views
8

Actualmente estoy trabajando en un proyecto y me he topado con un poco de scratch. He estado programando en Java durante aproximadamente dos años, y he cubierto excepciones, pero nunca las he entendido correctamente.Dónde manejar una excepción

En mi situación actual Tengo mi principal método que inicializa una clase

WikiGraph wiki = wiki = new WikiGraph(getFile()); 

El constructor Wikigraph toma un nombre de archivo, que llego a través de un DialogBox en el método getFile().

El constructor para wikigraph luego llama a un método llamado loadfile(filename) que intenta cargar y analizar el archivo dado.

El método loadfile() es donde lanzaré un IncorrectFileTypeError.

Mi pregunta es, ¿dónde debo manejar esto?

En el momento en que se captura en el loadfile() método

try { 
    //load file 
} catch (IncorrectFileTypeError e){ 
    System.out.println("Incorrect file type: "+filename+": "+e.getMessage()); 
    throw new IncorrectFileTypeError(); 
} 

Pero también lo cojo en la inicialización WikiGraph así:

while(wiki==null){       //While There is no valid file to add to the wikigraph 
    try { 
     wiki = new WikiGraph(getFile()); //Try to load file 
    } catch (IncorrectFileTypeError e) { //If file cannot be loaded 
     JOptionPane.showMessageDialog(null, "Incorrect File Type Given. Please Choose another file."); //Display error message 
     getFile();       //Prompt user for another file 
    } 
} 

Ahora es la forma en que he controlado el error la forma correcta/mejor? ¿O debería manejarse en otro lugar, como en el método getFile()?

EDITAR: Supongo que debería hacer que el problema del archivo sea un poco más claro. La extensión de archivo no es en lo que se basa el IncorriseFileTypeError, y por lo tanto puede ser un nombre de error engañoso. El archivo proporcionado puede tener prácticamente cualquier extensión, es el contenido de eso debe estar bien formado.

+0

Esta es una vista subjetiva de cómo las personas manejan el manejo de excepciones. Colocaría esto en el Wiki de la comunidad – Ascalonian

Respuesta

4

En este caso, evitaría usar excepciones como su método principal para tratar con tipos de archivos incorrectos. Si una excepción se puede desencadenar regularmente por la entrada del usuario, realmente no se debe tratar como una excepción. Aquí está el enfoque que tomaría:

  1. Compruebe el tipo de archivo y avise al usuario si el tipo de archivo no es válido, a través del flujo de control estándar. Puede considerar un método estático en WikiGraph como IsFileValid (nombre de archivo)
  2. En la inicialización de WikiGraph, ejecute una excepción si el tipo de archivo no es válido.

Este enfoque le ofrece lo mejor de ambos mundos: tiene la oportunidad de alertar a los usuarios cuando se proporcionan datos no válidos, al tiempo que garantiza desde la perspectiva de WikiGraphs que la información proporcionada es precisa. Le da a los desarrolladores que trabajan contra un WikiGraph una forma de garantizar que su entrada sea válida sin requerir necesariamente el manejo de excepciones.

+0

Ah sí, pero mi extensión de archivo no está establecida. Me dieron un archivo .idx de muestra para procesar. Puede ser .txt, o cualquier otra cosa, por lo que no puedo verificar en función de la extensión del nombre de archivo, solo en el contenido del archivo. El método isFileValid() tendría que analizar el archivo para verificar que sea válido, por lo que, dado que eso está sucediendo en el método loadfile(), ya no debería atraparlo allí. –

+0

Sí, desafortunadamente ese tipo de problemas pueden surgir. Todavía recomendaría fallar en el nivel UI sin excepciones si hay una verificación relativamente simple que se puede hacer en el archivo (es decir, verificando el encabezado), pero para verificaciones más complicadas es posible que deba verificar en loadfile()) –

+1

@Chris: Estoy en desacuerdo. Si el archivo no es válido, obviamente la instancia de WikiGraph que intenta crear no se puede inicializar correctamente. Permitir instancias parcialmente inicializadas es muy peligroso. Así que simplemente dejaría que el constructor declare la excepción, luego pondré un try-catch alrededor del constructor. El intento, por supuesto, aún incitaría al usuario. – sleske

1

No creo que tenga sentido atraparlo en loadfile. Todavía puede escribir un mensaje de registro (use System.err), simplemente hágalo antes de lanzar la excepción. Está en el camino correcto con la excepción de que puede hacer algo al respecto (en este caso, preguntar al usuario de nuevo).

+1

+1 para "atrapar la excepción donde se puede hacer algo al respecto", pero -1 para "Aún puede escribir un mensaje de registro". Por favor, * por favor * para no registrar y arrojar (ver, por ejemplo, http://codemonkeyism.com/7-good-rules-to-log-exceptions/, "no iniciar sesión y volver a lanzar"). La excepción * será * manejada en alguna parte, y allí debe tomarse la decisión de iniciar sesión. De lo contrario, obtendrá dos entradas de registro para un error, lo que puede ser extremadamente confuso. – sleske

+0

Nunca dije volver a lanzar. Dije log "antes de lanzar la excepción". En este caso, creo que el archivo de carga es el único nivel apropiado para iniciar sesión. –

3

Uno de los principales beneficios de las excepciones es que le brindan medios convenientes para manejar una excepción lejos de donde se produce. En los idiomas que no lo admitan, habría tenido que hacer que cada llamada en la ruta verifique el valor de retorno, corte y regrese, para que se propague manualmente.

Tiene sentido manejar la excepción donde cree que puede recuperarse o informar mejor y cancelar la operación.

Según entiendo, la interacción comienza con la entrada de UI y, si el tipo de archivo es inapropiado, no se puede recuperar realmente. Por lo tanto, quisiera que cualquier tarea de UI que iniciara el archivo abierto capte la excepción, informe al usuario de que se produjo un error y cancele o solicite una entrada diferente.

En una segunda lectura, parece que está abriendo el cuadro de diálogo después de que ya comenzó a intentar crear el gráfico. Personalmente me gusta aislar la interacción de UI. Por lo tanto, primero personalmente manejaré todas las entradas UI, obtendré el nombre esperado del archivo, verificará si cumple con mis necesidades, informaré al usuario si no, y solo continuaré más si el archivo está bien, y luego informaré de errores críticos e inesperados.

1

Si el problema es que el usuario ha elegido un archivo del tipo incorrecto, entonces no creo que deba dejar que el código proceda tan lejos. Esto realmente no parece que debería ser una Excepción en absoluto, sino más una ruta en el programa. Si el usuario ha seleccionado un tipo de archivo incorrecto, se le debe presentar la opción de elegir el archivo nuevamente. Obviamente, debe limitar las opciones en JFileChooser a los archivos del tipo correcto si es tan fácil como mirar la extensión.

1

Creo que este es el tipo de situación para la que están diseñadas las excepciones comprobadas (ya sea que las acepte o no). Supongo que IncorrectFileTypeError se extiende a Error? Extender RuntimeException sería más apropiado, y ampliar IOException sería mejor aún, porque este tipo de error puede desencadenarse mediante una entrada de usuario válida (es decir, escribir el nombre de un archivo que existe pero tiene el tipo incorrecto)

0

Creo este tipo de error (IncorrectFileTypeError) se puede resolver en el Formulario de entrada de usuario evitando un viaje de ida y vuelta innecesario a la capa de servicio del sistema de archivos.

Cuestiones relacionadas