La Gestione delle eccezioni in Java di Applicazioni Web

Sto sviluppando una dimensione media di Applicazioni Web Java con Struts come framework MVC e semplice JDBC a Livello di Accesso ai Dati. Sono stato alla ricerca per la gestione delle eccezioni le migliori pratiche in un’applicazione. Ho trovato diversi articoli, di cui alcuni in fase di contraddittorio, solo mi rende più confuso, piuttosto che fare le cose semplici e chiare. Alcuni dicono che è meglio riutilizzare le eccezioni esistenti invece di definire applicazione di specifiche eccezioni, altri presentano una vasta gerarchia di applicazione specifiche eccezioni, per tutti i piccoli problemi che possono verificarsi nel sistema. Alcuni dicono che è meglio non maneggiare le eccezioni a Livello di Accesso ai Dati e delegare loro per il Livello di Servizio, altri dicono che Livello di Accesso ai Dati eccezioni devono essere catturati localmente, poiché si delega a Livello di Servizio, violerebbe l’astrazione tra i due strati. E così via.

Sarei molto grato se mi fate sapere di link e/o i nomi degli articoli/libri che presentano soluzioni solide che hanno lavorato per voi in un tale scenario. La soluzione dovrebbe cancellare almeno i seguenti punti con giustificazioni:

  1. Dove il SQLExceptions essere catturato?
  2. In cui le eccezioni devono essere registrati?
  3. Dovrebbe eccezioni unchecked essere registrato?
  4. Dovrebbe eccezioni unchecked essere catturato a livello di presentazione, devono essere mostrato all’utente?
  5. Come eccezioni selezionate essere gestito, che, per essere mostrato all’utente e come?
  6. Come dovrebbe globale gestore di eccezioni di pagina da utilizzare?
  7. Come dovrebbe struts ActionErrors essere utilizzati in questo contesto?

Grazie

InformationsquelleAutor craftsman | 2010-01-30

 

3 Replies
  1. 20

    1: Dove il SQLExceptions essere catturato?

    In classi DAO a livello di accesso ai dati. Si può, se necessario, avvolgere con un custom DAO eccezione. Questo DAO eccezione a sua volta necessita di essere trattato più come eccezione controllata.

    2: Dove eccezioni devono essere registrati?

    Al momento in cui stai per throw loro o passare attraverso la messaggistica quadro.

    3: in caso di eccezioni unchecked essere registrato?

    Dovrebbero certamente essere registrato. Dovrebbero cioè non si verificano nel mondo reale, perché quelli sono il segno di un difetto del codice di logica (cioè colpa degli sviluppatori) che deve essere bugfixed al più presto. Essi dovrebbero essere gettato tutta la strada fino al contenitore e lasciare che la maniglia del contenitore con un <error-page> in web.xml. Per accedere (ed eventualmente di posta elettronica), utilizzare un Filter che si mette in ascolto sulla pagina di errore.

    4: in caso di eccezioni unchecked essere catturato a livello di presentazione, devono essere mostrato all’utente?

    Non dovrebbero verificarsi.

    5: Come eccezioni selezionate essere gestito, che, per essere mostrato all’utente e come?

    Se essi sono il risultato di errorneous input dell’utente (ad esempio, non è un numero, bad e-mail, violazione del vincolo, ecc), mostrare loro la stessa forma per l’utente. In caso contrario (ad esempio, DB, DAO eccezione e così via) sia per gettare tutta la strada fino alla pagina di errore, o visualizzare l’errore con un messaggio di riprovare più tardi.

    6: Come dovrebbe globale gestore di eccezioni di pagina da utilizzare?

    Almeno in un modo user-friendly. Così, nella stessa disposizione, con alcuni introduttiva “mi dispiace”, e, se necessario, con qualche errore di dettagli e di un indirizzo email in modo che l’utente può rivolgersi per caso.

    7: Come struts ActionErrors essere utilizzati in questo contesto?

    Visualizza nella stessa forma per l’utente.

    • Grazie per la risposta. Per quanto riguarda #3, come possiamo catturare un’eccezione non gestita nel Filtro, se il filtro è in ascolto sulla pagina di errore?
    • Memorizzato come attributo di richiesta con il nome exception. D’altra parte, è anche possibile gestire l’eccezione e in avanti per la pagina di errore di filtro, semplicemente mettendo chain.doFilter(request, response) all’interno di un blocco try/catch.
  2. 4

    Se riesci a recuperare da un’eccezione, allora si dovrebbe lasciare che il flusso di codice (spesso facendo la spunta, o avvolgendolo in un unchecked exception). Se rimangono selezionata, è necessario soddisfare per ogni livello di codice, e, di conseguenza, ad ogni livello di astrazione. SQLExceptions normalmente rientrano in questa categoria (dovrete avvolgere dal momento che sono controllati).

    Queste eccezioni, io di solito registro al più alto livello, ma è presente una pagina per gli utenti semplicemente dettaglio che qualcosa è andato storto. Normalmente i miei utenti non sono interessati in tracce dello stack. Ma io di solito offrire loro una pagina per permettere loro di descrivere che cosa stavano facendo, e il connesso eccezione si ricollega a questo invio tramite un id univoco (registrato nella forma e nel file di log con l’eccezione). Che mi permette di legare indietro le azioni degli utenti derivanti eccezione.

    Quanto sopra presuppone che non è possibile recuperare da SQLExceptions, e se il database è in basso, quindi non è possibile fare qualcosa di significativo. Ci sono eccezioni, naturalmente. Si potrebbe scoprire che si sta parlando di sistemi multipli, e uno in giù non significa che non si può continuare in qualche modo (ad esempio Amazon home page riferito, si basa su 100 servizi, e deve funzionare a prescindere di alcuni di questi in fase di discesa).

    Mi aspetterei dichiarato eccezioni di essere allo stesso livello di astrazione, come l’interfaccia/metodi di definizione. ad esempio, un TradeStore sarebbe dichiarato per lanciare una TradeException, non SQLException (dato che i metodi di memorizzazione di un commercio di attuazione di TradeStore – è possibile memorizzare in un db relazionale, un JavaSpace etc.).

    • Grazie Brian. +1 per il TradeStore esempio.
  3. 1

    Come un avvertimento, quando la visualizzazione di livello inferiore messaggi di errore per gli utenti, assicurarsi che si sta sanitized di informazioni di sistema. Questa è una zona dove molti exploit di sicurezza hanno origine. Registro con le informazioni complete, ma solo la visualizzazione di un più generale messaggio di errore all’utente.

Lascia un commento