Gestione delle eccezioni Java all'interno di "eventi"

Question

Vorrei ricevere un secondo parere su come gestire le eccezioni all'interno di "eventi" (inserimento chiave, aggiornamento schermo ecc.). In questo caso ho il controllo sul mittente dell'evento.

Quindi un modulo è impostato per gestire un evento (che implementa un'interfaccia ascoltatore, ed è registrato nei confronti di un mittente evento):

public void DefaultSet (CardData oldDefault, CardData newDefault) 
{ 
} 

Il mittente evento è semplicemente:

 for (Enumeration e = listeners.elements(); e.hasMoreElements();) 
     { 
      RetrieverListener thisListener = (RetrieverListener) e.nextElement(); 
      thisListener.DefaultSet(oldDefault, newDefault); 
     } 

Così se/quando qualcosa va storto nel ricevitore:

• Se dovessi provare ad affrontare l'eccezione il re, e non restituire mai nulla al mittente? A volte gli ascoltatori non hanno il "contesto" per gestire correttamente un errore, giusto?

• È corrugato per restituire un'eccezione a un modulo di invio eventi, da gestire in modo documentato? per esempio. "Lanciare una IOException comporterà un reset ..". Questo sembra non standard dalle javadoc che ho letto.

• Devo solo accedere e ignorare l'eccezione quando qualcosa va storto & non si può fare nulla al riguardo?

Answer 1

La convenzione Java è che i metodi di ascolto non generano eccezioni. Ovviamente, gli errori di programmazione potrebbero far sì che un listener lanci una RuntimeException, ma in nessun caso l'origine degli eventi può ripristinarla perché avrebbe lasciato gli oggetti del programma in uno stato sconosciuto, forse incoerente.

Spetta quindi all'ascoltatore rilevare le eccezioni controllate e recuperarle (ad esempio, ripristinare una transazione) o segnalarle a un altro oggetto. Io uso spesso un'interfaccia ErrorHandler che sembra qualcosa di simile:

public interface ErrorHandler { 
    public void errorOccurred(String whatIWasTryingToDo, Exception failure); 
} 

Un listener di eventi racconta la sua ErrorHandler sugli errori che si sono verificati.

public class SomeClass implements SomeKindOfListener 
    private final ErrorHandler errorHandler; 
    ... other fields ... 

    public SomeClass(ErrorHandler errorHandler, ... other parameters ...) { 
     this.errorHandler = errorHandler; 
     ... 
    } 

    public void listenerCallback(SomeEvent e) { 
     try { 
      ... do something that might fail ... 
     } 
     catch (SomeKindOfException e) { 
      errorHandler.errorOccurred("trying to wiggle the widget", e); 
     } 
    }   
} 

ho inizializzare i listener di eventi con un'implementazione di questo che si occupa il fallimento in qualunque modo un senso a quel punto l'applicazione. Potrebbe apparire una finestra di dialogo, mostrare un'icona di errore lampeggiante nella barra di stato, registrare un messaggio di controllo o interrompere il processo, ad esempio.

Answer 2

Quando non è possibile eseguire alcuna operazione, è necessario accedere e inviare un messaggio all'utente. Se qualcosa va storto che può danneggiare i dati o dare risultati errati se non puoi recuperare dovresti chiudere l'applicazione.

Answer 3

L'approccio normale è ignorare il problema. Gli ascoltatori non dovrebbero lanciare eccezioni incontrollate.

Un approccio migliore sarebbe prendere e registrare RuntimeException s. Questi generalmente indicano un errore di programmazione. Se un widget sullo schermo genera un NPE, non c'è motivo per cui il resto della finestra non debba finire di colorare. L'utente può quindi salvare i propri dati e riavviare o comunque aggirare il problema. Nel caso di Error s in genere significa che c'è una situazione grave, come ad esempio OutOfMemeory e l'acquisizione si tradurrà solo in thrashing. Nessuno si preoccupa di farlo.