On Wed, Apr 30, 2014, at 04:30 PM, Jens Alfke wrote: > > On Apr 30, 2014, at 4:00 PM, Jonathan Hull <jh...@gbis.com> wrote: > > > I also find that it is good practice to set variables returned by reference > > to nil before passing them. > > NSError *error = nil; > > Otherwise, they will contain garbage, and cannot reliably be tested to see > > if the value was set. > > That’s still not a good idea. If the call succeeds, it’s not guaranteed > that the error value is unchanged. It might have been set to some > intermediate error value, for example. > If the call failed, the error will contain a valid value whether or not > you initialized the variable, so there’s no need to initialize it. > > tl;dr: NEVER use the error value to determine whether or not the call > succeeded. Use the return value for that. Only look at the error if the > return value told you the call failed.
FWIW, there is at least one Apple API that requires you to check the error rather than the return value. All Apple APIs should now be leaving the error parameter alone in success cases. And with ARC, all object pointers are initialized to nil, even local variables. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
