Dlaczego wysyłanie dowolnego selektora do obiektu Nil nic nie robi, ale wysłanie „nieprawidłowego” selektora do dowolnego obiektu NSO powoduje wyjątek?

Czy ktoś wie, dlaczego NextStep / Apple zdecydował się przyjąć „wygodną metodę” polegającą na nie robieniu niczego podczas przekazywania obiektu Nil wiadomości, ale „metody Java” wywołania wyjątku podczas przekazywania instancji obiektu nieprawidłowego selektora?

Na przykład,

// This does "nothing"
NSObject *object = Nil;
[object thisDoesNothing];

object = [[NSObject alloc] init];
// This causes an NSInvalidArgumentException to be raised
[object thisThrowsAnException];

Z jednej strony mamy wygodę, że nie musimy sprawdzać Nil (zakładając, że nie przejmujemy się zbytnio wynikiem wywołania metody) - ale z drugiej strony musimy sprawdzić wyjątek, jeśli nasz obiekt nie odpowiada na metodę?

Jeśli nie jestem pewien, czy obiekt odpowie, muszę:

@try {
    [object thisThrowsAnException];
} @catch (NSException *e){
    // do something different with object, since we can't call thisThrowsAnException
}

Lub,

if([object respondsToSelector:@selector(thisThrowsAnException)]) {
    [object thisThrowsAnException];
}
else {
    // do something different with object, since we can't call thisThrowsAnException
}

(To ostatnie jest prawdopodobnie lepszym sposobem, ponieważ jeśli obiekt jest zerowy, selektor NIE wzbudziłby wyjątku, dlatego twój kod może nie zachowywać się tak, jak chcesz).

Moje pytanie brzmi: DLACZEGO Apple zdecydowało się wdrożyć to w ten sposób?
Dlaczego nie rozpoznane wywołanie selektora do obiektu instancji nie powoduje wyjątku?
Alternatywnie, dlaczego obiekt Nil nie zgłosi wyjątku, jeśli spróbujesz wywołać na nim metodę?

questionAnswers(3)

yourAnswerToTheQuestion