[JAVA] Gestione dei messaggi di errore

[puntino]

Salve

Ho l'esigenza di gestire in maniera sensata gli errori della mia web application.
Giusto per farvi un esempio supponiamo che la mia web application deve inserire un nuovo utente su di un database. Gli errori che mi aspetto sono del tipo
"Non è possibile inserire utente sul database" , ad esempio perchè già è presente oppure potrei avere un errore "Non è possibile effettuare quest'operazione" perchè il db non è raggiungibile e via dicendo.
Questi errori sono messaggi che io visualizzo all'utente e vorrei sapere come gestirli, per il momento ho inserito le suddette stringhe nel codice.
La mia idea è quella di associarare un codice di severità agli errori es E1, E2 ecc ad ogni messaggio. I codici con i messaggi sono inseriti in una tabella e quando si verifica una condizione di errore li prelevo dal db e stampo il messaggio.
Poi vorrei che lo stesso errore sia memorizzato in un'altra tabella "eventi" (oppure in un file) che mi inidica quando si è verificato. A imite a valle di un errore si può anche chiedere l'intervento dell'amministratore.
Come potete vedere nn sto parlando di codice ma come affrontare questo problema in maniera che gli errori siano gestiti in maniera coerente e sensata. Voglio capire dal punto di vista logico prima di sviluppare del codice.
Mi dispiace se forse ho inserito questo post nella sezione poco appropriata, anche se la mia web application è sviluppatata in java.
Vi ringrazio sin da adesso
PS ho provato a fare ricerche on line ma trovo sempre qualcosa legata al linguaggio e non ad una metodologia.

[standard]

Mi sembra che il tuo approccio sia buono, in linea con quanto mi è capitato di vedere in diversi gestionali.
Ovviamente ti sconsiglio di "cablare" stringhe e messaggi nel software (spesso il messaggio da inserire lo richiede esplicitamente il tuo utente), mentre invece ti consiglio di far viaggiare codici d'errore che poi si vanno a decodificare in una (o più) tabella centralizzata.

E' buona norma (magari in previsione di una maggiore scalabilità e portabilità su differenti contesti/clienti che usufruiscano del tuo software) prevedere uno "scope" del tuo errore, al fine di poter customizzare gravità e messaggi d'errore a seconda che l'errore sia sollevato da una particolare mappa o funzionalità o servizio.

Censire gli errori avvenuti in tabella è buona norma, soprattutto in un contesto batch.
In un contesto on-line è bene poter pilotare tale censimento tramite degli "interruttori" (properties o configurazioni sulla base dati), in modo che tu possa spegnerlo nel caso impatti sulle performance e lasciare al solo log su server il compito di riportare il problema.

[puntino]

in primis grazie per la tua risposta

Originariamente inviato da standard
Mi sembra che il tuo approccio sia buono, in linea con quanto mi è capitato di vedere in diversi gestionali.
Ovviamente ti sconsiglio di "cablare" stringhe e messaggi nel software (spesso il messaggio da inserire lo richiede esplicitamente il tuo utente), mentre invece ti consiglio di far viaggiare codici d'errore che poi si vanno a decodificare in una (o più) tabella centralizzata.

ok come faccio a capire di quante tabelle ho bisogno?
Per "richiamare" gli errori dal DB ovviamente mi creo una classe dedicata che ad esempio ha fra i suoi metodi qualcosa del tipo String getError( int errorCode).

Come si assegna la gravità agli errori, cioè supponendo che la gravita va da E1 a E5 con E1 più grave di tutti, come faccio a dire questo errore è di tipo E1 questo E2 e così via?
C'è qualche regola/principi che mi può guidare?
[/QUOTE]

E' buona norma (magari in previsione di una maggiore scalabilità e portabilità su differenti contesti/clienti che usufruiscano del tuo software) prevedere uno "scope" del tuo errore, al fine di poter customizzare gravità e messaggi d'errore a seconda che l'errore sia sollevato da una particolare mappa o funzionalità o servizio.

Si ricollega alla mia domanda di prima, per favore mi potresti fare un esempio ?

Censire gli errori avvenuti in tabella è buona norma, soprattutto in un contesto batch.
In un contesto on-line è bene poter pilotare tale censimento tramite degli "interruttori" (properties o configurazioni sulla base dati), in modo che tu possa spegnerlo nel caso impatti sulle performance e lasciare al solo log su server il compito di riportare il problema.

Non ho mai sentito parlare delle properties dove posso trovare qualche informazione ?
Grazie di nuovo

[standard]

Premetto che non vorrei darti una soluzione (anche perchè, più o meno simili, ne ho viste diverse ed ognuna con le sue peculiarità), ma uno spunto per permetterti di progettare la tua soluzione.

La progammazione ad oggetti ti consiglia due cose:
1) definire un oggetto per le tue entità: anche un errore potrebbe essere un'entità corredata di attributi (descrizione breve, descrizione lunga, gravità, ecc.)
2) mantenere gli oggetti separati (avere dei moduli e del software dedicato alla gestione, che sia (in teoria) modificabile nel caso la tua gestione degli errori cambi, senza impattare pesantemente le logiche ed il codice del resto del tuo applicativo.

L'assegnazione della gravità dell'errore è un ambito "funzionale". Ovvero chi definisce le logiche del tuo business, definisce anche se per un particolare errore ci sia un comportamento diverso e quindi una gravità dell'errore diversa.
Se fai tutto tu, allora sei tu a decidere in base a regole di usabilità e opportunità.

Lo stesso vale per lo scope (qualora abbia senso prevederlo).
Un esempio? supponiamo che hai due mappe o due funzionalità da cui sia possibile censire un soggetto. O meglio ancora supponiamo che vendi il tuo applicativo a due clienti diversi.
Supponiamo che il primo (cliente, mappa o funzionalità) voglia che, a fronte dell'errore "Utente già presente sul database", voglia procedere comunque ad un nuovo inserimento (magari un caso di omonimia) ed il secondo (cliente, mappa o funzionalità), a fronte dello stesso errore, voglia fermarsi e recuperare il cliente già inserito.

Gestendo uno scope (per cliente, mappa o funzionalità) dello stesso errore, puoi assegnare differenti gravità (e di conseguenza azioni) da assegnare al tuo errore.
Spero d'esser stato chiaro.

per properties intendo file di testo accedibili dalla tua web-application (in genere con estensione .properties) su cui sono riportare elenchi di chiavi=valore che possano configurare o personalizzare il comportamento del tuo software.
E' solo uno dei modi per parametrizzare la configurazione del tuo applicativo