Sto gestendo le mie eccezioni in modo ragionevole?

2

Sto ancora ristrutturando il codice che mi è stato dato per l'aggiornamento sul mio attuale progetto di lavoro, e sono giunto al punto in cui sto osservando come il codice gestisce un input 'eccezionale', che non conforme alla logica aziendale.

In sostanza, il codice unisce insieme diversi fogli di calcolo Excel, li ritarda e consente all'utente di "scaricarli" nel proprio spazio di lavoro per un'analisi successiva.

Questo è ciò che ho impostato nel codice:
Se il codice finisce (ovunque) cercando, ad esempio, di importare un foglio di calcolo vuoto nel libro di lavoro finale (qualcosa che non dovrebbe mai accadere, sotto la logica aziendale) quindi scrivere su una variabile LinkedList (ErrorList) in una classe statica ( MyVariables) mi piace così, l'errore:

MyVariables.ErrorList.add("My Specific Error Text");

Quindi lancio un'eccezione in questo modo:

throw new PICNICException();

Quindi nel frame che ha chiamato la scia dei metodi, l'eccezione è finalmente catturata e posso scrivere qualcosa del genere:

catch(PICNICException Pe){
    JOption.showMessageDialog(This, MyVariables.ErrorList.getLast(), "Title Relevant to what Code is Doing", JOption.ERROR_DIALOG)
   Pe.printStackTrace();
}

I hanno sento che devo farlo perché, non ho modo di far apparire la finestra di dialogo dei messaggi (che è il comportamento desiderato in caso di errore) dal metodo che ha generato questa eccezione. Senza completamente che refactoring l'intero codice base e rendendo un singleton accessibile ovunque per gestire questi dialoghi di messaggi, non vedo nessun altro modo per farlo.

Non posso fare a meno di pensare che si tratti di un gigantesco trucco, e c'è un metodo migliore per farlo.

Sto gestendo le mie eccezioni nel miglior modo possibile, data la mia situazione ? Quale sarebbe la migliore pratica?

    
posta Pureferret 03.04.2013 - 18:19
fonte

3 risposte

3

Lanciare le eccezioni non è male, il lancio di eccezioni per una situazione non eccezionale è considerato scadente, ma sembra che tu stia lanciando un'eccezione per un motivo eccezionale, quindi penso che vada bene.

Cose che terrei a mente però:

  1. Genera un'eccezione specifica
  2. registra le informazioni prima che l'eccezione venga lanciata
  3. Richiama nella documentazione che questo metodo può generare l'eccezione

Oltre a questo, non dovremmo cercare di evitare eccezioni in tutti i casi - sono davvero utili, non dovremmo usarle per il flusso di controllo standard.

    
risposta data 03.04.2013 - 18:24
fonte
3

Il tuo uso delle eccezioni sembra del tutto appropriato qui.

Il codice incontra una situazione che non dovrebbe mai verificarsi e che non può gestire in modo ragionevole a livello locale. Sembra il tipo di situazione per cui sono state pensate eccezioni.

Tuttavia, ho anche alcuni punti di critica:

  1. Il nome dell'eccezione non sembra indicare quale tipo di problema ha incontrato il codice (mi sarei aspettato qualcosa sulla falsariga di EmptyWorkbookException ). Ciò significa che in seguito sarà più difficile implementare una gestione degli errori diversa per problemi diversi (ad esempio, un errore richiede una casella di messaggio "Critico", mentre un altro richiede una finestra di messaggio "Avviso")
  2. Invece di usare la variabile separata ErrorList , è meglio generare il messaggio visibile all'utente nel punto in cui lo si visualizza (e quindi anche sapere quale lingua usare), o metterlo nell'oggetto eccezione si. La prima opzione è generalmente preferita per il testo visibile all'utente finale, quindi non devi preoccuparti della localizzazione ovunque. La seconda opzione dovrebbe essere utilizzata per trasportare informazioni in generale dal sito di lancio al sito di cattura.
risposta data 03.04.2013 - 19:12
fonte
2

In questo caso rimuoverei la ErrorList e includo un qualche tipo di chiave lunga con l'eccezione ad es. :

throw new PICINCException(ErrorKey.EMPTY_SPREADSHEET);

La chiave di errore viene quindi mappata in una serie di messaggi con messaggi di errore specifici per la GUI. Questo ha alcuni vantaggi rispetto alla soluzione attuale:

  1. Tutti i tuoi messaggi di errore si trovano in un unico posto che li rende facili da aggiornare.
  2. Se hai la possibilità di localizzare l'app (sembra improbabile ma rimarrai sorpreso) sarebbe più facile fare impostazioni locali specifiche per gli utenti.
  3. Con un'appropriata denominazione dovrebbe essere ovvio a chiunque legga il codice cosa sta succedendo con un'esposizione ridotta ("Vedo un enum ErrorKey in modo che debba mappare ai messaggi di errore").
  4. Riduce la piastra della caldaia attorno all'aggiunta di ErrorList, quindi lancia l'eccezione, cosa succede se dimentico di aggiungere a ErrorList e poi lancio un'eccezione?
risposta data 03.04.2013 - 19:31
fonte

Leggi altre domande sui tag