On Feb 8, 2016, at 7:15 AM, Dave <[email protected]> wrote: > > myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID]; > if (myUserInfo != nil) > { > LTWAssertAlways(@"myUserInfo - Dupe ID!!!!!!!!!!"); > } > > if (theUserInfo.pUserID != nil) > //Remove this Line for Warning > [self.pUserIDDict setObject: theUserInfo forKey: theUserInfo.pUserID]; > //Warning on this line! > } > > > I get a warning saying that Key argument for setObjectForKey cannot be nil? I > am wondering why it suddenly started moaning about this here and not other > places were it is used and could be nil, like this: > > myUserInfo = [self.pUserIDDict objectForKey: theUserInfo.pUserID]; > > This is the only place I’ve seen this warning and I’m using keys that could > be nil in lots of places (without any problems as I obviously make sure that > I don’t pass a nil…..
I suspect that you haven't shown us the whole code. The analyzer does not necessarily check every possible variable or property as to whether it could be nil in each code path. That's because programs can be written such that that's never the case, but in a way that the analyzer can't tell that, and to warn about every possible such situation would make the analyzer useless due to too many false positives. But, if your code _explicitly introduces_ the possibility that a value might be nil, with a check for that, then the analyzer then does check whether it may be nil in a place where it's not allowed. So, I suspect your code has a check which explicitly introduces the possibility of theUserInfo being nil, making the analyzer consider that. If you are using an assert to document that theUserInfo is not nil, then: a) your assert should boil down to a function which is annotated with __attribute__((__noreturn__)); and b) you should make the assertion macro the thing which tests the condition, rather than using an "if" statement combined with an assert-always macro like shown in the above code. The reason for (b) is that, if there's a compilation mode where the assert macros are disabled (which I don't recommend), then you want the check of the condition to also go away so the analyzer isn't confused. Regards, Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
