• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: how to test for NULL (or nil, or null)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to test for NULL (or nil, or null)


  • Subject: Re: how to test for NULL (or nil, or null)
  • From: "Louis C. Sacha" <email@hidden>
  • Date: Sun, 29 Feb 2004 15:13:48 -0800

Hello...

First, based on the information you provided, the object you are recieving is [NSNull null]. NSDictionary (and other collection objects) will not accept nil pointers to objects, so [NSNull null] is used instead, as a placeholder. When you recieve [NSNull null] it means that it was deliberately inserted into the dictionary for that key, since if the key did not exist the result of objectForKey: would be nil instead.

When you use %@ in the format for a string, if the the object used for the argument is not already an NSString, the results of [object description] are used. I haven't checked to make sure, but I'm relatively sure that the result of [[NSNull null] description] is probably @"NULL", which is why your NSLog statement is saying what it does.

/* all code typed in mail, untested, etc... */

As far as getting rid of the warning, you could probably just change the first line to

id myNumber = [myDictionary valueForKey: @"MyNumber"];

You could also use the isEqual: method for the test

if ([myNumber isEqual:[NSNull null]])


I would actually suggest using a different sort of test, which would check the class of the returned object instead:

if ([myNumber isKindOfClass:[NSNumber class]]) { ... object is an NSNumber ... }
else { ... object could be NSNull or some other class ... }

This has the benefit of catching anything that is not the class you expect, for example if somehow the object was actually an NSString instead of an NSNumber for some reason.

Although, come to think of it, NSString responds to intValue also and might be able to provide a valid result anyway, so an even better test might be

if ([myNumber respondsToSelector:@selector(intValue)]) { ... you can ask for object's intValue ... }
else { ... object could be NSNull or some other class that doesn't respond to intValue... }

It may not be possible in your case for the returned object to be anything other than an NSNumber or [NSNull null], but if the dictionary is coming from a source you don't control, it might be a good idea to use either of the more comprehensive tests.


Hope that helps,

Louis


I'm sure this is a question that has been asked before, but I can't find it despite keeping the last 22,210 messages on this list in my mailbox.

I have a cocoa / objective-C app that reads from a MySQL database that unfortunately has some NULL values where there should be numbers. As these NULLs tend to respond badly to a request for intValue I need to detect them before applying that code.

To my surprise I find that tests for == nil do not work. After much experimentation, and a little research (might have been better the other way) I now have code that works, but the compiler gives me a warning message, which makes me think the code could be better.

can anybody help me unravel the various forms of nil/null/NULL ?

Here's what I have (simplified):

NSNumber *myNumber = [myDictionary valueForKey: @"MyNumber"];
NSLog(@"myNumber = %@", myNumber); // output myNumber = NULL
if (myNumber == nil)
NSLog(@"test 1 myNumber == nil); // never happens
if (myNumber == NULL)
NSLog(@"test 2 myNumber == NULL); // never happens
if (myNumber == [NSNull null])
NSLog(@"test 3 myNumber == [NSNull null]);

The third test works, so I get output:
myNumber = NULL
test 3 myNumber == [NSNull null]

Unfortunately the compiler doesn't think much of the test that works, and warns "comparison of distinct pointer types lacks a cast"

I'm thinking that the valueForkey finds a match, but that match is a NULL, so myNumber gets to have value NULL rather than having no value. This is why "if (myNumber == nil)" doesn't work, but why doesn't "if (myNumber == NULL)" work? My NSLog line claims that myNumber has a value NULL, but a test for == NULL does not succeed.

Even though I now have code that works I'm not happy with that warning message.

Denis
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Prev by Date: Re: Databasing and Cocoa
  • Next by Date: Re: Preference dialog
  • Previous by thread: Re: how to test for NULL (or nil, or null)
  • Next by thread: Controller introspection API
  • Index(es):
    • Date
    • Thread