objectForKey stringValue crashing my app?

Question

I have a class that I use to setup objects in an array. In this class I have a custom "initWithDictionary", where I parse a JSON dictionary. However, as I am running into NSNull, this crashes my app. To get around this, I set up a class that handles exceptions, so when a string is NSNull, it's replace it with @"". or -1 for integers.

This is my NullExtensions class:

@interface NSNull (valueExtensions)

-(int)intValue;
-(NSString *)stringValue;

@end

@implementation NSNull (valueExtensions)

-(int)intValue {
    return -1;
}

-(NSString*)stringValue {
    return @"";
}

@end

However, in my initWithDictionary method, the following code crashes my app:

self.bookTitle = [[parsedDictionary objectForKey:@"book_title"] stringValue];

It doesn't work regardless of the object in the parsed dictionary being NSNull or containing a valid string. Only if I do the following (and the string is not null):

self.bookTitle = [parsedDictionary objectForKey:@"book_title"];

Is stringValue incorrect in this case? And if so, how do I use it properly in order to setup proper NSNull replacements?

Thx

Answer 1

You really really don't want to add a category to NSNull that adds such common methods. That will change the behavior of NSNull for all instances in the application, including ones created by the underlying frameworks solely for their private use.

If you need a value class that represents the notion of "value doesn't exist and therefore I'm going to return these default values instead", create a class or instance that represents exactly that.

As for why it crashes, I couldn't tell you without seeing the actual details of the crash.

---

And, yes, it really is THAT bad to add a category to a class that adds such a common method. All it takes is one bit of code in a plug-in or framework that does:

if ([fooMaybeNull respondsToSelector: @selector(intValue)] bar = [fooMaybeNull intValue];

Not terribly farfetched -- I have had to debug nasty crashers or misbehaviors due to exactly this kind of willy-nilly category addition.

If you are going to add methods to a class via categories, prefix your method names so as to isolate them from existing functionality. It is still fragile, but manageably so.