Eccezioni per l'azione

Indietro 1 2 3 4 Pagina 3 Avanti Pagina 3 di 4

Esempio di serie di eccezioni

Nella Figura 1 vengono visualizzati quattro tipi di eccezioni progettate per eseguire quattro tipi di azione, come segue:

  1. BusinessException : si è verificata una condizione eccezionale. Questa condizione era prevista e può essere verificata con il metodo chiamante per un'azione immediata.
  2. ParameterException : i dati inseriti non consentono una corretta elaborazione. All'utente deve essere richiesto di reinserire dati validi o di modificare le condizioni in cui avviene l'elaborazione.
  3. TechnicalException : si è verificato un problema tecnico come un'istruzione SQL non valida. L'operazione richiesta non può essere eseguita. L'utente deve contattare l'help desk per indagini o provare un altro servizio. L'uso dell'applicazione da parte di altri utenti non viene influenzato.
  4. CriticalTechnicalException : si è verificato un problema tecnico come un arresto anomalo del database. In queste condizioni l'intera applicazione è inutilizzabile. L'utente dovrebbe essere incoraggiato a riprovare più tardi. Gli altri utenti non dovrebbero utilizzare l'applicazione fino a quando non è stata riparata.

Questo insieme di eccezioni è solo un esempio; molti altri set di eccezioni potrebbero essere definiti in modo simile. Ad esempio, TechnicalExceptione CriticalTechnicalExceptionpotrebbe essere progettato come una singola classe di eccezione con un severityattributo booleano . L'importante è concentrarsi sul tipo di azione che dovrebbe essere intrapresa, piuttosto che sulla questione che ha sollevato l'eccezione.

Registrazione delle eccezioni

Sebbene la semantica delle eccezioni si concentri sull'azione da intraprendere, anche il problema sollevato è importante. Il team di sviluppo potrebbe, ad esempio, utilizzare queste informazioni per eseguire il debug del codice. Nella mia progettazione delle eccezioni, le informazioni sulla causa dell'eccezione possono essere trovate nel file di registro degli errori dell'applicazione. Con un buon framework di registrazione in atto, dovrebbe essere sufficiente registrare le informazioni sul problema dal messaggio di eccezione e dall'analisi dello stack.

L'unico problema che rimane in come progettare l'eccezione in modo che queste informazioni possano essere facilmente recuperate. Una soluzione è fornire all'eccezione un attributo id che rappresenti il ​​tipo di problema in questione. Inoltre, se il problema ha generato la propria eccezione, questa eccezione può essere nidificata nell'eccezione dell'applicazione. Al momento della cattura, il messaggio originale e l'analisi dello stack possono essere recuperati dall'eccezione nidificata. L' attributo id e la nidificazione delle eccezioni sono due modi per includere le informazioni relative al problema nell'eccezione stessa.

Progettare il flusso delle eccezioni

Dopo aver progettato le eccezioni stesse, il passaggio successivo consiste nel pensare a come fluiranno attraverso l'applicazione. Un'architettura applicativa JEE standard è composta principalmente da quattro pacchetti: presentazione, business, integrazione e persistenza. Le eccezioni vengono in genere generate dai pacchetti di integrazione e persistenza. Nel pacchetto aziendale, i livelli di runtime interni rilevano le eccezioni controllate non appena possibile, mentre i livelli esterni rilevano le eccezioni di runtime e intraprendono le azioni appropriate in base alla loro classe. Puoi anche lanciare e catturare alcune eccezioni controllate all'interno del pacchetto aziendale. In questo schema, la responsabilità dei pacchetti di integrazione e persistenza, così come del livello interno del pacchetto aziendale, è convertire le eccezioni di runtime in azioni.Una tipica architettura di applicazione JEE di questo tipo è mostrata nella Figura 2.

Il percorso di un'eccezione generata dal pacchetto di persistenza (ad esempio) dipende da dove è possibile risolvere il problema. Se il metodo chiamante è in grado di risolvere il problema, l'eccezione viene rilevata immediatamente, viene intrapresa l'azione appropriata e l'attività prosegue normalmente. Se il problema non può essere risolto, l'eccezione viene annidata in un'eccezione di runtime e trasmessa silenziosamente attraverso i livelli intermedi del pacchetto aziendale ai livelli superiori dell'applicazione. In questi livelli, tipicamente da qualche tipo di controller dell'applicazione, viene rilevata l'eccezione di runtime, viene eseguita l'azione appropriata e il livello di presentazione mostra all'utente il messaggio di errore corrispondente. La cattura immediata delle eccezioni verificate e la cattura tardiva delle eccezioni di runtime sono i due scenari principali in questo tipo di progettazione delle eccezioni, come mostrato nella Figura 3.