Is it kosher to use the NSNull category trick to avoid problems with NSNull's performSelector: ...?
In our project, we sometimes get our iPhone app that crashes when something on the network returns JSON with zero in it. Of course, we have a helper class that takes care of such problems. However, people are error prone and call objectForKey on NSDictionary instead of our own stringForKey or dateForKey etc. There is now a class to kill all such problems once and for all: https://github.com/nicklockwood/NullSafe
My question is, is NullSafe really safe? Because sometimes you want your program to crash if the logic is wrong and you get NSNull. Just ignoring the problem hides it. The app probably won't crash, but it will do something strange in some cases.
Now I'm leaning towards not using this class, and just making sure our JSON NSDictionaries are filtered from all NSNulls before we try to parse the resulting values (it might have a performance impact though).
What do you guys think?
source to share
This class is safe from the point of view of not crashing the application when you send any message to it. It behaves like a value nil
.
This class does not resolve errors! If you can get it NSNull
, you should act as it is and handle the case.
Once I used a class like this (also because of JSON) but I put NSLog
(or a ratcher breakpoint) in a method -forwardInvocation:
to see where it was called from and why . I would not use this in production.
You also asked about performance. Not sure if more is required: deleting NSNull
from an array or searching all classes for their method signatures;)
source to share