Il mio lavoro è quello di far rispettare le mie precondizioni?

1

Dire che ho una funzione che accetta alcuni argomenti che ricadono in una serie di vincoli, ad es. uno di loro deve essere un numero intero, un altro deve essere una stringa di lunghezza di almeno 10, eccetera. In generale, è responsabilità dello sceneggiatore di funzioni (cioè mio) avere un gruppo di assert s o qualsiasi altra cosa per far rispettare queste precondizioni e generare errori se qualcuno vi viene violato? O dovrei semplicemente lasciare che la funzione proceda comunque e fare in modo che il chiamante si occupi degli errori o degli strani output che ottengono da esso? Il mio ragionamento è che da un lato, è più semplice in termini di debugging se viene immediatamente generato un errore quando viene violata una condizione preliminare, ma d'altra parte, potrebbe essere più semplice per il chiamante leggere la documentazione della funzione piuttosto che me imbottendolo con un intero carico di assert se if -statiments.

Come una domanda a parte, se sto scrivendo funzioni che userò solo io, la risposta è la stessa, o faccio solo ciò che mi sembra più comodo?

    
posta Bluefire 17.10.2016 - 21:35
fonte

2 risposte

4

È importante controllare i parametri in alcune condizioni.

  • Hai un'unità di lavoro o una transazione che non puoi eseguire il rollback a metà

  • L'errore generato senza controllo sarebbe inutile: "l'oggetto è null"

  • Nessun errore verrebbe generato, ma il risultato sarebbe errato o confuso "e dove nome == null"!="e nome == qualsiasi valore"

  • Il lavoro costoso o dispendioso sarebbe senza risultato

Ma sì, se hai una funzione semplice e sta per lanciare un'eccezione ragionevole comunque non farei il controllo dei parametri.

Inoltre, se puoi scrivere la tua funzione in modo tale che sia difficile che i parametri siano sbagliati, è sempre una buona cosa.

    
risposta data 17.10.2016 - 22:09
fonte
4

Questo è piuttosto soggettivo e dipende dall'ambiente culturale.

Generalmente, è spesso un approccio praticabile per:

  • genera eccezioni nella tua interfaccia pubblica (ad esempio controlli a basso costo sugli input)
  • usa le asserzioni nel tuo codice privato (controlla le proprie chiamate, stato, ecc.)

Entrambi gli strumenti supportano diversi tipi di cose: il primo aiuta l'utente a utilizzare il codice nel modo corretto. Il secondo ti aiuta a eseguire il debug del tuo codice (ciò che l'altro ragazzo potrebbe non essere in grado di fare comunque).

Modifica: più a lungo penso a questo, più apprezzo il controllo dell'input / condizione.

Supponiamo che tu stia implementando function foo(some_input) .

Qualcun altro lo usa e, ad un certo punto, il programma si blocca, con una traccia dello stack giù nella libreria. È estremamente difficile da rintracciare cosa è andato storto, e potrebbe anche non iniziare con foo() , ma più avanti sulla linea. L'origine del problema può sembrare del tutto estraneo alle condizioni necessarie alla tua funzione. Se il tuo codice salva lo stato, potrebbe accadere ore più tardi.

Chi sarà accusato? Sembra che il tuo codice sia rotto (anche se tecnicamente potrebbe essere ok come da documentazione). Ed è praticamente impossibile risolvere il problema senza grandi sforzi.

O dì che la persona usa anche un'altra libreria di terze parti, ad esempio function bar() . Potrebbe fare:

some_input = bar();
result = foo(some_input);

E se sorgono problemi, possiamo giocare a puntare il dito, tutti indovinano chi è il diavolo.

Bottom line: Be has helpful as you can! It will make life so much easier. You will get much less support request. And - best of all - you won't be held responsible for other people's bugs.

    
risposta data 17.10.2016 - 21:42
fonte

Leggi altre domande sui tag