Best practice per creare un modello di codici di errore per un progetto Enterprise in C # [chiuso]

C'è una differenza tra i codici di errore e i valori di ritorno dell'errore. Un codice di errore è per l'utente e l'help desk. Un valore di ritorno dell'errore è una tecnica di codifica per indicare che il tuo codice ha riscontrato un errore.

Si possono implementare i codici di errore usando i valori di ritorno dell'errore, ma vorrei sconsigliarlo. Le eccezioni sono il modo moderno di segnalare errori e non vi è alcun motivo per cui non dovrebbero contenere un codice di errore al loro interno.

Ecco come lo organizzerei (si noti che i punti 2-6 sono indipendenti dal linguaggio):

1. Utilizza un tipo di eccezione personalizzato con una proprietà ErrorCode aggiuntiva. Il fermo nel ciclo principale riporterà questo campo nel modo consueto (file di registro / errore pop-up / risposta di errore). Utilizza lo stesso tipo di eccezione in tutto il tuo codice.
2. Non iniziare da 1 e non utilizzare gli zeri iniziali. Mantieni tutti i codici di errore alla stessa lunghezza, quindi è facile individuare un codice di errore errato. A partire da 1000 di solito è abbastanza buono. Magari aggiungi una "E" iniziale per renderli chiaramente identificabili per gli utenti (particolarmente utile quando l'help desk deve istruire gli utenti su come individuare il codice di errore).
3. Tieni un elenco di tutti i codici di errore, ma non lo fanno nel tuo codice . Mantieni una breve lista su una pagina wiki per gli sviluppatori, che possono facilmente modificare quando hanno bisogno di un nuovo codice. L'help desk dovrebbe avere un elenco separato sul proprio wiki.
4. Non provare a imporre una struttura sui codici di errore. Ci saranno sempre errori difficili da classificare e non si vuole discutere per ore se un errore dovrebbe essere nel gruppo 45xx o nel gruppo 54xx. Sii pragmatico .
5. Assegna a ogni lancio del codice un codice separato. Anche se pensi che sia la stessa causa, l'help desk potrebbe aver bisogno di fare cose diverse in diversi casi. È più facile per loro avere "E1234: Vedi E1235" nella loro wiki, piuttosto che chiedere all'utente di confessare ciò che ha fatto di sbagliato.
6. Dividi i codici di errore se l'help desk lo richiede. Una semplice riga if (...) throw new FooException(1234, ".."); else throw new FooException(1235, ".."); nel tuo codice potrebbe risparmiare mezz'ora per l'help desk.

E non dimenticare mai che lo scopo dei codici di errore è semplificare la vita per l'help desk .

Devi prima isolare le aree in cui potrebbero verificarsi errori e essere visibile all'utente. Quindi puoi documentarli. È così semplice.

Beh, in teoria semplice .. in pratica gli errori possono verificarsi in tutto il dannato posto, e riportarli può trasformare un bel codice in un mostro di logging, lancio di eccezioni e gestione e il passaggio dei valori di ritorno.

Consiglierei quindi un approccio in 2 fasi. Il primo è registrare, registrare un sacco e un sacco.

In secondo luogo è determinare i principali componenti e le loro interfacce e definire i principali casi di errore in cui questi componenti possono trovarsi. È quindi possibile accedere in modo più visibile quando uno di questi errori (il modo in cui si gestisce l'errore internamente è fino a te - eccezioni o codici di errore non fanno differenza qui). Generalmente un utente vedrà l'errore e passerà ai registri per ottenere informazioni più dettagliate.

Lo stesso approccio viene utilizzato per i server Web e il tuo esempio di codice di errore http. Se l'utente vede un 404 e lo segnala per supportare, cercherà nei registri i dettagli di ciò che stava succedendo, quale pagina è stata visitata, quando, e potrà raccogliere qualsiasi altra informazione possibile da qualsiasi altra parte abbia senso , essere nel DB, nella rete o nell'applicazione.

Vorrei andare su eccezioni personalizzate con nomi descrittivi e messaggi chiari e lanciarli. È molto più semplice utilizzare l'infrastruttura di eccezione esistente di una lingua piuttosto che creare supporto per trasmettere codici di errore e interpretarli.