On Oct 2, 2009, at 4:05 AM, Gregory Weston wrote:
While we're at it, the values of enc and error are (effectively)
nondeterministic before the message send. The documentation for the
method you're invoking doesn't specify what it'll put into the
encoding argument on failure or into the error argument on success,
which means you really shouldn't be blindly using either of them
after the call. It would be a good idea to get into the habit of
initializing your local variables at the point of declaration.
That is partially correct; you should never assume anything about the
values of enc and error after the call. Period. No amount of
initialization is going to change this.
Consider this code:
NSStringEncoding enc = nil;
NSError *error = nil;
NSString *file = [NSString
stringWithContentsOfFile:@"/Users/colin/developer/Trace/glass.csv"
usedEncoding:&enc error:&error];
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.
In either case, assuming the undefined reference is nil would be a
bug. Initializing the variables to nil prior to the call isn't going
to change anything in that regard.
(And, yes, there are methods that modify their error parameter on
success -- purely an implementation detail. Perfect valid thing to
do since the return value is undefined on success.)
b.bum
_______________________________________________
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
