Eccezioni che catturano il codice della clutter e rendono difficile la lettura

Question

Eccezioni che catturano il codice della clutter e rendono difficile la lettura

#1 da (3 voti)

4

Quando leggo un codice ben scritto che controlla che tutto l'input sia del formato e del tipo corretti, e rilevi anche tutte le cose che potrebbero andare storte, trovo difficile capire il nocciolo di ciò che il programma è facendo. Sembra che la protezione contro il caso non normale oscuri il caso normale.

Questo include l'inizio e la fine di casi speciali di array, try-catch, uso, gestione di null, 0, "" e tutte le altre cose strane.

Come posso scrivere codice che è chiaro, ma non è disordinato da eventi non normali ??

Per rendere questo un po 'più concreto, come posso farlo in C #?

readability exceptions

posta Anthony 24.02.2014 - 01:52

fonte

1 risposta

Leggi altre domande sui tag readability exceptions

Punti di ingresso multipli nel progetto Record di database sintetici

score 3 · Accepted Answer

Ci sono tre cose specifiche che faccio nel mio codice per risolvere questo problema:

Ritorno anticipato / interruzione / continua

Anche se un numero di persone disapprova questo fatto come "un goto", aiuta a chiarire molto il tuo codice. Quando hai un test che rileva una condizione eccezionale, gestisci la condizione ed esci dal metodo in cui ti trovi, invece di ingombrare il metodo con un enorme if / else.
Rompi il tuo codice in blocchi di normale esecuzione significativa, circondato da try ... catch blocks

Quando hai un pezzo di codice che potrebbe lanciare un'eccezione, invece di gestire immediatamente l'eccezione, inserisci tutto il codice che potrebbe essere associato al codice rischioso all'interno del blocco try ... catch. In questo modo, il blocco si legge come un pezzo significativo di codice. In un certo senso questo è l'opposto del primo suggerimento, ma si tratta di eccezioni generate invece di condizioni booleane.
Sposta il codice di lancio delle eccezioni in un metodo separato, in modo che le eccezioni siano trattate in un metodo e il codice rischioso venga eseguito in un altro

Questa è solo una versione estrema della seconda raccomandazione. Se il normale flusso di logica è abbastanza grande da giustificarlo, spostalo in un metodo separato e chiama quel metodo all'interno di un blocco try ... catch. Questo può anche aiutare quando si hanno diversi livelli di controllo degli errori, separando i livelli è possibile rendere più facile la lettura del codice.

Il modo in cui questi suggerimenti sono applicati dipende da cosa il codice ti permette di fare. Scrivo anche dal punto di vista di un programmatore Java; Non so se ci sono altri meccanismi in C # che potrebbero essere d'aiuto.