• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Initializing NSError **, again Re: CoreData Migration Problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initializing NSError **, again Re: CoreData Migration Problems


  • Subject: Re: Initializing NSError **, again Re: CoreData Migration Problems
  • From: Matt Neuburg <email@hidden>
  • Date: Wed, 9 Feb 2011 09:09:55 -0800

On Tue, 8 Feb 2011 17:07:00 -0600, Fritz Anderson <email@hidden> said:
>On 8 Feb 2011, at 2:51 PM, Quincey Morris wrote:
>
>> P.S. It's OT, but initializing 'error' to nil before passing it to an error-returning method is both a waste of time and semantically incorrect -- it's an *output only* parameter to the method. OTOH, setting it to nil isn't inherently harmful. :)

We've been through this many times before, and I'm going to quote two different views (from this list, October 2009) that seem to me definitive. They are commenting on this code:

>      NSStringEncoding enc = nil;
>      NSError *error = nil;
>
>      NSString *file = [NSString
> stringWithContentsOfFile:@"/Users/colin/developer/Trace/glass.csv"
> usedEncoding:&enc error:&error];

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.

--
matt neuburg, phd = email@hidden, <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Initializing NSError **, again Re: CoreData Migration Problems
      • From: Quincey Morris <email@hidden>
  • Prev by Date: indeterminate progress bar animation and CALayer-backed sibling view
  • Next by Date: Re: CATransformLayer doesn't support implicit animation?
  • Previous by thread: Re: indeterminate progress bar animation and CALayer-backed sibling view
  • Next by thread: Re: Initializing NSError **, again Re: CoreData Migration Problems
  • Index(es):
    • Date
    • Thread