perché usare 'assert' in un progetto? (E perché usarlo così tante volte)

Question

stavo leggendo attraverso il codice ListAdder di esempio, e ci sono molti afferma subito dopo la variabile, o utilizzato in quasi tutti i metodi, per esempio:

self.formatter = [[[NSNumberFormatter alloc] init] autorelease]; assert(self.formatter != nil);

o :

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{ 
    #pragma unused(tv) 
    #pragma unused(indexPath) 
    UITableViewCell * cell; 

    assert(tv == self.tableView); 
    assert(indexPath != NULL); 
    assert(indexPath.section < kListAdderSectionIndexCount); 
    assert(indexPath.row < ((indexPath.section == kListAdderSectionIndexNumbers) ? [self.numbers count] : 1)); 

Mi chiedevo, qual è il punto di farlo?

Grazie

Answer 1

Si tratta di un'implementazione di Design by Contract o DbC.

L'obiettivo C non ha supporto nativo per le pre-condizioni, post-condizioni e invarianti di DbC, ma in particolare post e precondizioni possono essere implementate piuttosto bene con macro.

Ecco alcuni altri approcci per implementare DbC in Objective C:

• http://www.roard.com/contracts/
• http://lists.apple.com/archives/objc-language/2006/Sep/msg00000.html
• Il D programming language ha DbC, e qui è Michel Fortins tentativo lo stesso stile di DbC, ma per Obiettivo C: http://michelf.com/weblog/2010/dobjc-preliminary-design/

Answer 2

Il punto di affermazioni è quello di assicurarsi che i bug appaiono immediatamente, e in modi facilmente diagnosticabili, invece che come sottili comportamento scorretto in seguito. In questo caso, lo sviluppatore di quel codice vuole garantire che 4 condizioni siano valide dopo l'esecuzione del codice.

Answer 3

L'afferma verificare le ipotesi del programmatore su come verrà invocato il codice. Se le assunzioni sono sbagliate, l'asserzione fallirà e genererà un'eccezione. Questo fa fallire il codice il prima possibile.

se fare questo o non è un punto di dibattito. Può essere preso troppo lontano.