Quando iniziare a scrivere Gestione eccezioni, Registrazione

Quando inizi a scrivere il tuo codice di gestione delle eccezioni? Quando inizi a scrivere le dichiarazioni di registrazione.

Ai fini dell'elaborazione di questa domanda, supponiamo che siamo su una piattaforma .NET con registrazione log4net ma non esitate a rispondere in modo generico.

Soluzione: un progetto Windows Form. Progetti: UI, BusinessRules, DataHandlers

Quindi, ti occupi di scrivere i tuoi DataHandlers che eseguono prima le tue manipolazioni dei dati come Crea, Leggi, Aggiorna, Elimina.

Quindi segui le tue regole aziendali

E poi la tua UI o qualsiasi altra permutazione di cui sopra.

Prova la tua applicazione per funzionalità.

E quindi iniziare a scrivere il codice di gestione delle eccezioni e infine il codice di registrazione?

Quando è il momento giusto per iniziare a scrivere il codice di gestione delle eccezioni?

PS: Nel libro Clean Code , dicono Prima scrivi il tuo blocco try-catch-finally . Questo, mi ha spinto a porre questa domanda.

Scrivi il tuo codice di gestione delle eccezioni quando scrivi qualcosa che chiama qualcosa che potrebbe causare eccezioni.

Ad esempio, quando stai scrivendo qualcosa che invia dati a una rete, dovresti anche scrivere il codice che gestisce i timeout della connessione. L'eccezione è direttamente rilevante per quello che stai facendo e il lavoro è fresco nella tua mente.

D'altra parte, se si sta scrivendo un parser che genera eccezioni quando rileva un'unità dati di protocollo non valida, non è possibile scrivere codice di gestione delle eccezioni per le eccezioni prodotte dal parser . (Ma ovviamente stai scrivendo dei test per mostrare come, quando e perché il parser solleva eccezioni!)

Il motivo alla base del suggerimento di scrivere il tuo try-catch-finalmente prima è duplice: infine è per ripulire le risorse che la funzione crea / consuma, e scrivere il catch è un bel promemoria che le funzioni che stai chiamando potrebbero non funzionare, e devi gestire (se necessario) quei fallimenti.

Tendo ad aggiungere la registrazione dopo il fatto. Non sono sicuro che sia saggio, ma è proprio quello che ha funzionato per me. Quando inizio a eseguire test di accettazione e simili e inizio a colpire i problemi, quindi aggiungo la registrazione in modo da poter tenere traccia degli errori. (E poi lascio il login.)

Nella mia esperienza, se non si scrive il codice con la gestione e la registrazione degli errori appropriate dall'inizio, non verrà eseguito a causa della pressione del tempo. Gli sforzi di sviluppo di maggior successo che ho intrapreso sono iniziati con il tempo speso a determinare la struttura di base delle applicazioni, incluso lo standard di codifica, la modalità di gestione degli errori, la registrazione, l'architettura di base e gli strumenti di test.

In caso contrario, scoprirai di avere attività per la versione 2.0 come "Migliora la gestione degli errori" e "Crea sistema di registrazione". Questi saranno tagliati a favore di nuove funzionalità e poiché hai "troppo da fare", correggendo tutti quei bug nei casi di errore a cui non hai pensato. (Il che richiede un'eternità, perché non hai un sistema di registrazione.

Dipende da cosa stai facendo

per eccezioni:

Se stai scrivendo qualcosa che potrebbe avere errori o qualcosa in cui ci sono buoni punti di livello superiore per lasciare che le eccezioni saltino fuori per scriverli mentre vai.

Se stai scrivendo qualcosa che ha bisogno di prestazioni e ha una bassa possibilità di errori e manca un posto significativo dove mettere i gestori di errori scrivi i gestori di errori in cui il test dimostra che ne hai bisogno.

In entrambi i casi, se non hai nulla di utile a che fare con l'errore, considera di lasciarlo gonfiare (nessun gestore)

per la registrazione:

Se è necessaria una pista di controllo, è necessario innanzitutto scrivere la registrazione. Se si lasciano gli errori in bolla fino in cima, è necessario fornire anche alcuni log in modo da poter acquisire il registro.

A parte questi casi, in genere aggiungo il logging solo nei punti in cui il test / uso dimostra che è necessario e di solito faccio un'opzione per configurarlo quando ho finito.

È possibile implementare il controllo e la gestione delle eccezioni come servizi. La registrazione di controllo a livello di applicazione richiede dati sullo stato di ciascuna transazione aziendale. La capacità di monitorare un'applicazione in un contesto aziendale o transazionale richiede un'interfaccia di monitoraggio all'interno del servizio per inviare messaggi che dettagliano lo stato della transazione specifico all'invocazione del servizio. Ciò richiede che ciascun servizio invii un messaggio di stato in fasi critiche della transazione commerciale. È quindi possibile creare un visualizzatore in tempo reale per correlare i messaggi di stato (in base alla semantica del messaggio, ad es. ID transazione) con i servizi all'interno dell'applicazione composita. Ciò fornisce una visione end-to-end della transazione commerciale per la gestione degli SLA, la tracciabilità dei guasti e la determinazione dei problemi.

Un servizio di audit può quindi essere implementato come una macchina a stati in grado di consumare e registrare messaggi in base a criteri definiti nella sua configurazione. Un gestore di eccezioni generico può anche utilizzare il servizio di controllo per supportare una visione centralizzata dei problemi che si verificano nella SOA aziendale - per supportare il monitoraggio basato sulle eccezioni. Qualsiasi condizione che non si dovrebbe verificare nella soluzione è strumentata per inviare un messaggio di eccezione al gestore eccezioni.

Scrivilo quando ne hai bisogno, ma progetta per la loro inclusione dall'inizio.

In altre parole: crearlo in modo che esista un modo per gestire quella capacità di registrazione e aggiungere la funzionalità effettiva di dadi e bulloni (quali messaggi registra) in un secondo momento in caso di necessità. Su eccezioni, aggiungi il trucco (e infine se ce l'hai) prima di scrivere il tiro. Ciò contribuirà a evitare di dimenticarne uno e salvarti un'iterazione o, nel peggiore dei casi, un bug / crash.