2011-12-19 31 views

Respuesta

38

Esto está bien siempre que pueda confiar en que el código al que está pasando el nil no intentará llamarlo como un bloque.

una rápida demostración:

typedef void (^GenericBlock)(void); 

void useThisBlock(GenericBlock block){ 
    block(); 
} 

useThisBlock(^{NSLog(@"All okay.");}); 
useThisBlock(nil); // Compiles but crashes 

El código interno debe comprobar el primer bloque: if(block) block();

En el caso del código UIKit, que debe estar bien.

+2

"* En el caso del código UIKit, debería estar bien. *" ¿Se necesitan citaciones? – Manav

+0

@Manav: No está equivocado, no hay forma de verificarlo (excepto que no se cuelga). –

6

Pasar nil está bien, y en mi opinión produce un código de lectura más limpio.

Si no desea utilizar un bloque de finalización, en este caso también puede utilizar el método [UIView animateWithDuration:animations:].

+0

Gracias, sé que hay un método sin bloque de animación. Mi pregunta es más acerca del bloqueo en sí mismo. Entonces, ¿por qué 'nil', no' NULL'? – pixelfreak

+0

'nil' y' NULL' son equivalentes. Por convención, Objective-C normalmente usa 'nil' donde' NULL' se usa en C. – sho

+10

que no es exactamente así en ARC. 'nil' significa objeto y se debe usar donde se espera' id', mientras que 'NULL' significa un puntero no válido no objeto y se debe usar donde' 'void *)' se espera. Eche un vistazo a [this] (http://stackoverflow.com/questions/557582/null-vs-nil-in-objective-c) pregunta para obtener más información. –

Cuestiones relacionadas