Is returning NSNotFound for NSUInteger advisable?

Question

I'm working on a category for NSArray and one of the functions I've implemented is designed to return the number of strings (or not numbers) in the array. This all works fine, but my question is about the usage of NSNotFound as a return in the event that the input array's count is zero.

Apple's docs state:

NSNotFound is typically used by various methods and functions that search for items in serial data and return indices, such as characters in a string object or ids in an NSArray object.

This makes complete sense if I were to use indexOfObject: for an item that wasn't in the array. But, is using NSNotFound in the context demonstrated below correct usage? Sure I could just return zero and call it a day, but it would be helpful seeing 2147483647 and immediately knowing where the problem is.

- (NSUInteger)countOfStringsInArray {
    NSUInteger currentCount = 0;
    if ([self count] > 0) {
        for (id obj in self) {
            if (![obj integerValue]) {
                currentCount ++;
            }
        }
        return currentCount;
    }
    return NSNotFound;
}

Answer 1

No, not in this case. The method in the example returns a count. You would consider using/returning NSNotFound (for example) on a method which returns an index, where 0 is also a valid index and thus a misrepresentative result.

So "Yes, you should simply return 0 and the return type should be unsigned (NSUInteger)", since NSNotFound should not be associated to a count. That really covers your cases without dependance on a magic value.

If you favor knowing where the problem is (and I do this myself quite often), I find it preferable to instead just consider it a programmer error to call the method when the collection is empty.

Answer 2

I dont think a count can be called as NSNotFound. Count can only be 0 or more. It can never be 'not found', in my opinion. If that was the case [NSArray count] should return NSNotFound when the array is empty or array is nil, right? So in short, I feel that using NSNotFound in this particular case is not a standard way. At least apple would have never used it that way.

Probably you can use zero as the default case or else you might have to define your own enum to represent that. NSNotFound is useful only if you cant use zero as the default value(For those cases, -1 can be made as default value if that is acceptable or NSNotFound can be used since that represent the NSIntegerMax).

Answer 3

I see where you are coming from, particularly given the suggested usage of NSNotFound. For the subsequent developer who inherits this code, however, I don't think your suggested implementation would be intuitive.

I would recommend using an NSRange return value instead. Per Apple's definition, NSRange is "a structure used to describe a portion of a series—such as characters in a string or objects in an NSArray object." That's exactly what you've got.

Specifically, the location member of NSRange could be the index of the first string that you find in the array, and the length member could be the number of strings that you find.

And like other methods that return an NSRange (e.g., NSString:rangeOfString), you could set the location to NSNotFound if no strings are found.

Hope that helps.