Проверка «пустых» сбоев NSString, когда NSString не инициализирована

Question

У меня есть метод, в котором я хочу убедиться, что я делаю что-то особенное, когда сталкиваюсь с «пустой» строкой. Он прекрасно работает, когда на самом деле есть строка, или когда я специально установил ее на «nil» или «NULL», но вылетает, когда я пытаюсь протестировать неинициализированную строку NSString. Как мне справиться с этим сценарием?

Например:

-(void) WhyDoICrash
{
  NSString *foo;

  // Some other stuff...

  // foo should be considered "empty"
  if (foo == nil || foo == NULL || [foo length] == 0)
  {
    // whatever
  }
}

============= РЕДАКТИРОВАТЬ ===================

Хорошо, выше было просто ДЕЙСТВИТЕЛЬНО простой пример, который отображает проблему. Я фактически использую категорию для NSString, что означает, что некоторые из (хороших, но не применимых) рекомендаций, которые я получаю, не могут быть использованы. Вот мой точный код:

#pragma mark - NSString Category

@interface NSString (NullOrEmptyTesting)
+(BOOL) isNullOrEmpty: (NSString*)input;
@end

@implementation NSString (NullOrEmptyTesting)

+(BOOL) isNullOrEmpty: (NSString*)input
{
  return (input == (id)[NSNull null] || input.length == 0);
}

@end

Answer 1

(…), но происходит сбой при попытке проверить неинициализированную строку NSString. Как мне справиться с этим сценарием?

Вы обрабатываете это, инициализируя соответствующую переменную, например,

NSString *foo = nil;

Как в C, так и в Objective-C, автоматические переменные не инициализируются с 0 - вы не можете делать никаких предположений относительно значения, содержащегося в этой переменной. Смотрите этот вопрос: Что происходит с объявленной неинициализированной переменной в C? Имеет ли оно значение?

Кроме того,

if (foo == nil || foo == NULL || [foo length] == 0)

эквивалентно:

if (foo == nil || [foo length] == 0)

и, поскольку Objective-C поддерживает обмен сообщениями nil объекты , обычно тестируют:

if ([foo length] == 0)

только.

Обратите внимание, что Objective-C инициализирует экземпляр переменных с 0 при выделении экземпляра.

Answer 2

Вы бы не потерпели крах, если бы вы делали сравнение AND.

т.е.

if ((foo != nil) && (foo != NULL) && ([foo length] > 0))
{
    // do something
}

Причина, по которой вы терпите крах, состоит в том, что сравнения OR, которые вы делаете, оценивают все(включая [foo length], каждый раз).В этом случае вы отправляете сообщение недопустимому объекту, поэтому происходит сбой.

При выполнении сравнения AND.Успешный тест "foo == NULL" перестанет оценивать все остальное (так что вы не будете вдаваться - и вылетать - - [foo length])