C'è un modo per intercettare i messaggi inviati a zero in Objective-C?

Question

Sono appena stato morso da un fastidioso bug che è stato reso oscuro dal comportamento "invia messaggio a nil è ok" in Objective-C.

Ho visto Sending a message to nil? e il consenso sembra essere "questo è il modo in cui rotoliamo" in Objective-C.

Ora, forse non ho abbastanza esperienza in Objective-C, ma sembra che sarebbe utile per intercettare questo, perché non riesco a pensare a una buona ragione per cui questo dovrebbe accadere più di il tempo. Tuttavia, potrebbe essere solo un idioma di programmazione a cui non sono ancora abituato.

Così diverso da controllare per nil ovunque in questo modo:

assert(object != nil); 
[object message]; 

C'è un modo per rendere la trappola runtime questa condizione, e avvertire quando object è pari a zero?

Answer 1

È possibile utilizzare uno ObjC undocumented trick or dtrace (vedere i commenti per la soluzione dtrace).

pid$1::objc_msgSend:entry 
/arg0==0/ 
{ 
    ustack(); 
} 

Answer 2

nil messaggio viene utilizzato molto comunemente in ObjC. La gente può combattere se questo è buono o cattivo; è solo qualcosa a cui devi abituarti. Se provi a romperlo con trucchi, rompi Cocoa perché Cocoa lo usa. Ci sono alcuni trucchi (come diciu postati) che renderanno possibile eseguire il debug in situazioni in cui si sospetta che non ci siano messaggi, ma non riesco a trovarlo. Ma non puoi semplicemente lasciare quelli nel tuo codice (e il post del blog sopra lo rende chiaro). nil messaging è troppo comune all'interno dei framework.

al punto originale, però, confrontare:

- (void)doSomethingWith:(id)x { 
    NSAssert(x != nil, @"Don't pass me nil"); 
    [x something]; 
} 

vs.

void Bar::DoSomething(Foo *x) { 
    assert(x != NULL); 
    if (x != NULL) { 
     x.something; 
    } 
} 

In entrambi i casi, è necessario testare, e in entrambi i casi il compilatore non avvisa se non riesci a testare. L'unica differenza è in quali casi si blocca/asserisce. Personalmente, scrivo macro intorno a NSAssert() che lo rendono sempre stampa un messaggio di registro se fallisce. Si blocca solo in Debug. In questo modo quando un cliente mi invia i log, posso vedere quali asserzioni falliscono.