programmazione difensiva e gestione delle eccezioni

Question

Un paio di giorni fa, ho seguito le domande teoriche sul esame: (a) spiegare cosa si intende per la programmazione difensiva quando si tratta di circostanze eccezionali che possono verificarsi durante l'esecuzione di un programma . È possibile fare riferimento agli esempi visualizzati in classe o utilizzare il codice pseudo per descrivere i passaggi da intraprendere per impedire il verificarsi di determinate circostanze durante il tentativo di leggere un file, ad esempio. [5 voti]

(b) Descrivere brevemente in termini generali cosa si intende per gestione delle eccezioni in Java e in che modo si differenzia dalla programmazione difensiva. [5 voti]

Ho sempre pensato che la programmazione difensiva sia l'intero paradigma della programmazione e che la gestione delle eccezioni sia la parte di esso. Durante l'esame, scrivo che in "programmazione difensiva", il programmatore prova a scoprire tutti i possibili problemi prima di eseguire il codice logico, e successivamente restituisce il valore dell'errore (esempio 0) da questa funzione, mentre nella gestione delle eccezioni i potenziali errori si verificano e sono catturato da un meccanismo speciale, in cui questi errori vengono interpretati direttamente. È giusto? Quali dovrebbero essere le risposte corrette?

Answer 1

Programmazione difensiva, per me, significa scrivere codice per gestire casi che non pensate possano accadere, o addirittura che possano accadere, perché credete che le vostre convinzioni siano inaffidabili.

Ad esempio (non compilato o testati, applicare condizioni):

private String findSmallestString(Collection<String> strings) { 
    if (strings == null || strings.isEmpty()) return null; 
    Iterator<String> stringsIt = strings.iterator(); 
    try { 
     String smallestString = stringsIt.next(); 
     while (stringsIt.hasNext()) { 
      String candidateString = stringsIt.next(); 
      if (candidateString == null) continue; 
      if (candidateString.compareTo(smallestString) < 0) { 
       smallestString = candidateString; 
      } 
     } 
     return smallestString; 
    } 
    catch (NoSuchElementException e) { 
     return null; 
    } 
} 

Lì, caratteristiche probabilmente difensive includono:

• La clausola guardia nullo o vuoto in cima ; questo è un metodo privato, quindi dovresti essere in grado di assicurarti che non venga mai chiamato con una raccolta nullo o vuota
• Il try-catch per NoSuchElementException; puoi provare che il codice che contiene non getterà mai questa eccezione se l'iteratore soddisfa il suo contratto.
• La clausola di protezione null delle stringhe (diversa dalla prima!) Che esce dall'iteratore; ancora una volta, dal momento che questo è un metodo privato, probabilmente si dovrebbe essere in grado di garantire che il parametro di raccolta non contiene valori null (e che cosa faresti mettere i null in collezioni comunque?)

Non tutti sarebbero d'accordo che il nulla gli assegni sono difensivi. Il tentativo di cattura è, al punto di essere completamente inutile.

Per me, il test dell'acido della programmazione difensiva è che non pensate che la difesa verrà mai utilizzata.

Answer 2

Per me la programmazione difensiva sta presupponendo il caso peggiore: i tuoi utenti sono pazzi e devi difendere te stesso e il tuo programma dai loro input pazzi. Credo che ci sia un sacco di saggezza all'interno di questa citazione:

Ogni giorno, l'industria del software sta facendo il software più grande e migliore infallibile, e ogni giorno, la natura sta facendo più grandi e migliori sciocchi. Finora la natura sta vincendo

E non dimenticare mai che i tuoi utenti non sono solo i tuoi clienti. Se sei responsabile di un'API di libreria, i tuoi utenti potrebbero essere un altro dipartimento.In questo caso uno dei più stellare si lamenta che io abbia mai sentito in vita mia è stato:

Anche dopo che abbiamo eliminato tutti i test di unità falliti, il programma non ha funzionato