There are multiple ways to implement such protection:
NSParameterAssert
__attribute__((nonnull))
- and a simple
if test.
[EDIT]
Since the latest Xcode versions (Xcode 6), Apple added nullability annotations which is another — and better — way to express if a parameter can be nil / null or not. You should migrate to that notation instead of using __attribute__((nonnull)) to make your APIs even more readable.
In details:
NSParameterAssert is Apple's dedicated macro that checks a condition on a method parameter and throws a dedicated exception if it fails.
- This is a protection only at Runtime
- This macro still considers that passing
nil as a parameter is a programmation/conception error, considering that due to your application workflow it should normally never happen (due to other conditions ensuring the param never being nil for example), and if it's not something really went wrong.
- It still thows an exception (that your calling code may
@try/@catch if necessary), but it has the advantage that the exception thrown is more explicit (telling that the parameter was expected not to be nil instead of crashing with an ugly and hard-to-understand callstack/message).
If you want to allow your code to call your method with nil but just do nothing in that case, you may simply if (!param) return at the beginning of the function/method.
- This considers that passing
nil is NOT a programmation/conception error and thus can sometimes happen due to the workflow of your application, so that's an acceptable case that can happen and just shouldn't crash.
Less commonly known, there is the __attribute__((nonnull)) GCC/LLVM attribute that is dedicated to tell the compiler that some parameters of a function/method are expected to be not-null. This way, if the compiler can detect at compile time that you try to call your method/function with a nil/NULL argument (like directly calling insertNameInDitionary:nil instead of using a variable which value can't be determined at compile time yet), it will emit a compilation error right away to let you fix it ASAP.
[EDIT] Since latest Xcode 6, you can (and should) use nullability annotations instead of __attribute__((nonnull)). See examples in Apple's Blog post.
So in summary:
If you want to mark that your method EXPECT your parameter to be non-nil, thus indicating that calling it with nil is a logic error, you should do the following:
- (void)insertNameInDictionary:(NSString*)nameString __attribute__((nonnull))
{
// __attribute__((nonnull)) allows to check obvious cases (directly passing nil) at compile time
NSParameterAssert(nameString); // NSParameterAssert allows to check other cases (passing a variable that may or may not be nil) at runtime
[myDictionary setObject:nameString forKey:@"Name"];
}
If you think that calling your method with nil can happen and is acceptable, and you just want to avoid a crash in those cases, simply do stuff like this:
-(BOOL)insertNameInDictionary:(NSString*)nameString
{
if (nameString == nil) return NO;
[myDictionary setObject:nameString forKey:@"Name"];
return YES;
}
And if you think that you should be able to insert a nil object in your dictionary, you can convert the nil value to NSNull in that specific case so that it insert the NSNull singleton that is dedicated to such usage (I used the short form of the ?: ternary operator to make the code more compact):
-(void)insertNameInDictionary:(NSString*)nameString
{
[myDictionary setObject:nameString?:[NSNull null] forKey:@"Name"];
}
And last case, if you want that passing nil in that particular example simply removes the Name from myDictionary, you can simply either do a simple if test and call removeObjectForKey:@"Name" if nameString is nil and call setObject:forKey: if it's not… or you could use KVC and the generic setValue:forKey: (KVC method, not specific to NSDictionary at all, so not to be confused with setObject:forKey:) that in the case of NSDictionary exactly has the same behavior (removing the key from the dictionary if we pass nil for the value parameter).