Manejo de excepciones en la GUI de Swing

Question

No estoy seguro acerca de cómo administrar las excepciones en la GUI; mi objetivo es informar al usuario si algo sale mal y aparece un mensaje inteligible.

Estoy pensando en hacer algo como esto:

// I'm inside an actionPerformed() method 
try { 
    // do whatever I have to do here 
} catch (KnownBusinessException1 e) { 
    // inform the user and do something; 
    // most times simply inform the user that it wasn't possible to complete the 
    // operation and remain in the same window instead of moving forward. 
} catch (KnownBusinessException2 e) { 
    // just as above 
} catch (KnownDataAccessException1 e) { 
    // just as above 
} catch (KnownDataAccessException2 e) { 
    // just as above 
} catch (RuntimeException e) { // I want to catch any other unexpected exception, 
// maybe NPE or unchecked IllegalArgumentExceptions and so on 
    // something went wrong, I don't know where nor how but I will surely inform the user 
} 

Ahora: Si en el bloque try hay excepciones para la captura de comprobarse, sería mejor para anidar un try/catch o para atrapar a estos comprobado excepciones después de atrapar RuntimeException? (Probablemente depende, ni siquiera sé si esto va a pasar por cierto)

Otra cosa: ¿qué hay de Error s? No me gustaría experimentar un cierre inesperado si fuera un usuario, prefiero que la aplicación me diga que algo salió muy mal y que nadie puede hacer nada al respecto, "el fin del mundo está llegando, así que saldrá en este momento ". Al menos sabría que no fue mi culpa jajaja.

Por cierto no sé si es una buena práctica para detectar errores ...: \

Hay una mejor manera de hacer esto en una aplicación Swing?

Answer 1

Si en el bloque try hay excepciones comprobadas para capturar, ¿sería mejor anidar un try/catch o atrapar estas excepciones marcadas después de capturar RuntimeException? (Probablemente depende, ni siquiera sé si esto va a pasar por cierto)

Como dijiste, depende de si tiene sentido ejecutar el resto del código en el bloque try después de la excepción sido atrapado Si no, no tiene sentido anidar los bloques try/catch.

Answer 2

Una buena manera de mostrar al usuario que algo ha salido mal es usar JOptionPane s. Agregue a eso un buen uso de los iconos (información/error) y listo. He aquí algunos ejemplos de código para su referencia:

http://docs.oracle.com/javase/tutorial/uiswing/components/dialog.html

Se puede considerar algunas clases de personalización/abstracción sobre JOptionPane si quieres :)

cuanto a manejo de múltiples excepciones de la misma manera, si el mensaje va a ser el mismo en todos los 3 KnownBusinessException sy KnownDataAccessException s entonces usted puede asegurarse de que ambas clases tengan el mismo parentesco y atrapen esa clase. Si se requiere el mismo tratamiento para KnownBusinessException sy no para KnownDataAccessException s, tenga todos los KnownBusinessException s con el mismo padre y todos KnownDataAccessException con el mismo padre. Espero que llegue a donde voy con esto.

Answer 3

Creo que lo mejor es capturar explícitamente todas las excepciones marcadas, e instalar un controlador de excepciones no detectadas para el resto. Ver esto: How can I detect when an Exception's been thrown globally in Java?

Ésta es la forma en que uso Thread.setDefaultUncaughtExceptionHandler:

public static void setupGlobalExceptionHandling() { 
    Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { 
     @Override 
     public void uncaughtException(Thread t, Throwable e) { 
      handleException(e); 
     } 
    }); 
} 

Tenga en cuenta que el truco "sun.awt.exception.handler" para el hilo EDT, mencionado en muchos de los mensajes, no es necesario y no funciona en Java 7. Para Java 7 solo use el Thread.setDefaultUncaughtExceptionHandler estándar como se describe arriba. Por supuesto, si usa ambos mecanismos para registrar el manejador de excepciones, el código funcionará en todas las versiones.

Por cierto, el hilo EDT se reinicia automáticamente si se produce una excepción no detectada (pero su aplicación podría permanecer en un estado incoherente), ver esto: EDT and runtime exception