On Feb 9, 2011, at 09:09, Matt Neuburg wrote: > From Bill Bumgarner: > > >> If the method fails -- if file is nil -- the 'error' will be filled in >> with an [autoreleased] NSError instance describing the error. >> However, 'enc' will be undefined. >> >> If the method succeeds, file and enc will be non-nil references to the >> result, but 'error' will be undefined. >> > > From Ben Trumbull, in response: > >> Not initializing locals is imho, >> professionally, realistically, and morally wrong. It's just a bug >> waiting to happen. And you have to know it is, just looking at it. >> Whatever might have been saved / gained by not initializing them was >> wasted, for all of time, the first time I had to debug the segfault. > > So the take-home message is: To touch "error" after this call without first > learning that "file" is nil is wrong and can lead to undefined behavior. But > not to initialize a local pointer variable is an accident waiting to happen. > So my rule is: do initialize "error" to nil, but then follow the rules about > when it is safe to touch. m.
I'll go one more round on this before bowing out of the thread, since we've spent so much time on it in the past. The difference between the two luminary opinions you quote is that Bill's is a *technical* answer (technically correct, too), and Ben's is a *moral* position. Both are heartfelt, but I'm not sure that the world in general needs to give them equal weight. (In response to Ben, I'd say that if an object can't be given its real value via initialization, setting it to nil might avoid a segfault if it's used before getting set to a proper value, but that won't avoid the real bug in the code.) The real world cost in all of this is that it's easy for a developer to misunderstand the 'error:' parameter mechanism, in such a way as to code an error handling scheme that depends on initialization to a nil value to work properly. Writing examples that include the nil initialization just seem to me to promote the misconception (and that's a moral position on my part). _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
