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

Sto lavorando a un progetto aziendale che verrà implementato in molte PMI e imprese.
Il supporto per questo progetto sarebbe in difficoltà e quindi voglio creare un modello di codifica per errori ( come i codici di stato HTTP ). Ciò consentirà alle persone dell'help desk di fare riferimento ai documenti e di risolvere i problemi il prima possibile.

Quali sono le migliori pratiche e raccomandazioni per farlo?
Qualsiasi aiuto per fare questo sarà utile.

c# programming-practices error-handling enterprise-development

— Pooya
fonte

Ci sono troppe risposte possibili o buone risposte sarebbero troppo lunghe per questo formato. Aggiungi dettagli per restringere il set di risposte o per isolare un problema a cui è possibile rispondere in pochi paragrafi. E cosa hai provato finora.

— Ben McDougall,

Dipende da come è strutturata la tua attività. In C # abbiamo sempre offerto all'utente la possibilità di inviarci StackTrace o copiarlo / incollarlo dai dettagli del messaggio di errore (non avevamo requisiti di sicurezza rigidi).

— Falcon,

Risposte:

C'è una differenza tra codici di errore e 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 codice ha riscontrato un errore.

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

Ecco come lo organizzerei (nota che i punti 2-6 sono agnostici sulla lingua):

Utilizzare un tipo di eccezione personalizzato con una ErrorCodeproprietà aggiuntiva . Il fermo nel circuito principale riporterà questo campo nel solito modo (file di registro / pop-up di errore / risposta di errore). Usa lo stesso tipo di eccezione in tutto il tuo codice.
Non iniziare da 1 e non usare zeri iniziali. Mantenere tutti i codici di errore della stessa lunghezza, quindi è facile individuare un codice di errore errato. A partire da 1000 di solito è abbastanza buono. Forse aggiungi una "E" iniziale per renderli chiaramente identificabili per gli utenti (particolarmente utile quando il servizio di supporto deve istruire gli utenti su come individuare il codice di errore).
Tieni un elenco di tutti i codici di errore, ma non farlo nel tuo codice . Tieni un breve elenco 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.
Non tentare di applicare una struttura sui codici di errore. Ci saranno sempre errori difficili da classificare e non vorrai discutere per ore se un errore dovrebbe essere nel gruppo 45xx o nel gruppo 54xx. Sii pragmatico .
Assegna a ogni lancio nel tuo codice un codice separato. Anche se pensi che sia la stessa causa, l'help desk potrebbe dover fare cose diverse in casi diversi. È più facile per loro avere "E1234: vedi E1235" nella loro wiki, piuttosto che indurre l'utente a confessare ciò che ha fatto di sbagliato.
Dividi i codici di errore se l'help desk lo richiede. Una semplice if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");riga nel codice potrebbe risparmiare mezz'ora per l'help desk.

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

— Sjoerd
fonte

Non l'ho mai fatto personalmente, ma spesso vengono visualizzati anche "ID di correlazione", guide specifiche dell'istanza di errore che vengono visualizzate all'utente e registrate. In questo modo, è possibile trovare più facilmente la ricorrenza esatta dell'errore nei registri, più facilmente che con un tempo approssimativo e un codice di errore.

— xdhmoore,

Suppongo che ci sia probabilmente un modo per includere il codice di errore nell'ID di correlazione in modo che possa fungere da codice di errore leggibile dall'uomo per l'help desk e come ID di istanza di errore per gli sviluppatori.

— xdhmoore,

Il mio modello è abbastanza simile. Ma invece di "E", ho aggiunto una parte breve dell'app-parte. Il nostro framework di documentazione ha ad esempio un Doc1234po 'di tempo che l'app principale può avere IrS1234. Quindi i miei helpdesk-collaboratori sono abbastanza veloci nell'aiutare i miei utenti.

— Matthias Burger,

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

Bene, in teoria semplice ... in pratica possono verificarsi errori in tutto quel dannato posto, e segnalarli può trasformare un bel codice in un mostro di registrazione, lancio e gestione delle eccezioni e passaggio di valori di ritorno.

Vorrei quindi raccomandare un approccio in 2 passaggi. Il primo è quello di registrare, registrare lotti e lotti.

Il secondo è determinare i componenti principali e le loro interfacce e definire in quali casi di errore maggiori possono trovarsi questi componenti. È quindi possibile accedere in modo più visibile quando uno di questi errori (come gestire l'errore internamente dipende da te - qui le eccezioni o i codici di errore non fanno differenza). Un utente generalmente vedrà quindi l'errore e andrà nei registri per informazioni più dettagliate.

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

— gbjbaanb
fonte

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

— Stefan Billiet
fonte

Gradirei la persona che ha votato in negativo questa risposta da 1 a 0 per almeno dare un motivo ...

— Stefan Billiet,

non sono stato io a effettuare il downvoting (non è importante, superarlo), ma penso che esista anche un supporto per i valori di ritorno nella lingua.

— gbjbaanb,

Per me è importante; se sbaglio, vorrei sapere in modo da poter imparare :-p Come intendi, supporto esistente per i valori di ritorno? Non dovresti scrivere un impianto idraulico per differenziare un normale valore di ritorno da un codice di errore? Tradurre un'eccezione a un codice di errore al limite di un sistema è una cosa, ma manipolarli all'interno del sistema è qualcosa che è generalmente sconsigliato. Credo che The Pragmatic Programmer menzioni questo genere di cose.

— Stefan Billiet,

le eccezioni non sono un buon meccanismo in ogni caso, ma se hai deciso di utilizzare gli errori, puoi aggiungere un parametro out ad ogni chiamata o fare in modo che tutte le chiamate importanti restituiscano un codice. Decidi in anticipo di farlo e sei d'oro. Pragmaticamente, si finisce con un mix dei due: restituire i codici di errore ai confini (quindi non si è bloccati in una sola lingua) e usare le eccezioni internamente.

— gbjbaanb,

Non ti ho votato in basso (prendilo con calma, altrimenti tutti dovranno ripetere questo :). Se hai lavorato o chiamato nel service desk, è molto più semplice comunicare un breve numero piuttosto che un messaggio di errore. È garantito che un messaggio di errore cambi quando viene comunicato oralmente.

— Codismo,