Quando iniziare a scrivere Gestione eccezioni, Registrazione

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

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

D'altra parte, se stai scrivendo un parser che solleva delle eccezioni quando incontra un'unità di dati del protocollo non valida, non puoi scrivere il codice per la gestione delle eccezioni per le eccezioni che il parser produce . (Ma di corso stai scrivendo dei test per mostrare come e quando e perché il parser solleva eccezioni!)

Il motivo alla base del suggerimento di scrivere il tuo try-catch-finally è duplice: finalmente serve a ripulire le risorse che la funzione crea / consuma e scrivere catch ti ricorda che le funzioni che stai chiamando potrebbero non riuscire e devi gestire (se necessario) quei guasti.

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

Nella mia esperienza, se non si scrive codice con la corretta gestione degli errori e la registrazione dall'inizio, non verrà eseguito a causa delle pressioni temporali. Gli sforzi di sviluppo di maggior successo a cui ho partecipato sono iniziati con il tempo dedicato alla determinazione della struttura delle applicazioni di base, compresi lo standard di codifica, la gestione degli errori, la registrazione, l'architettura di base e gli strumenti di test.

Altrimenti, scoprirai di avere delle attività per la versione 2.0 come "Migliorare la gestione degli errori" e "creare il sistema di registrazione". Questi saranno tagliati a favore di nuove funzionalità e perché hai "troppo da fare", risolvendo tutti quei bug nei casi di errore a cui non hai pensato. (Che dura per sempre, perché non hai un sistema di registrazione.

Dipende da cosa stai facendo

per le eccezioni:

Se stai scrivendo qualcosa che probabilmente contiene errori o qualcosa in cui ci sono dei buoni punti di primo livello per far sì che le eccezioni divampino per scriverle mentre procedi.

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

In entrambi i casi, se non hai nulla di utile da fare con l'errore, prendi in considerazione di lasciarlo scoppiare (nessun gestore)

per la registrazione:

Se hai bisogno di una pista di controllo, devi prima scrivere la registrazione. Se stai lasciando che gli errori arrivino fino in cima è necessario fornire anche alcuni dati di registrazione, in modo che il registro possa essere catturato.

A parte questi casi, in genere aggiungo il log solo nei luoghi in cui il test / l'uso dimostra che è necessario e di solito faccio un'opzione per configurarlo una volta terminato.

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

Un servizio di revisione può quindi essere implementato come 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 vista centralizzata dei problemi che si verificano nell'azienda SOA aziendale - per supportare il monitoraggio basato su eccezioni. Qualsiasi condizione che non dovrebbe verificarsi nella soluzione è strumentata per inviare un messaggio di eccezione a gestore di eccezioni.

Scrivilo quando ne hai bisogno, ma progetta di includerlo dall'inizio.

In altre parole: rendilo così esiste un modo per gestire quella capacità di registrazione e aggiungere la funzionalità di dadi e bulloni effettivi (quali messaggi registra) in seguito, se necessario. Con le eccezioni, aggiungi il fermo (e infine se lo hai) prima di scrivere il tiro. Ciò ti aiuterà a non dimenticarti di uno ea salvarti da un'iterazione o, nel peggiore dei casi, da un bug / crash.