title: Understanding 'potential null dereference' when dealing with NSError
body: <p>I understand that this may seems a very basic question, but I always thought that explaining (and understanding) basic question is the key to build clean and working code. 
  I have the following fragment of code in a CoreData entity:</p>
  
  <pre><code>-(BOOL)validateForInsert:(NSError *__autoreleasing *)error {
      [super validateForInsert:error];
      return [self validateInternal:error];
  }
  
  -(BOOL)validateInternal:(NSError *__autoreleasing *)error {
    // checking attributes and build userInfo error
    if(anyErrors) {
      *error = [NSError errorWithDomain:appDomain code:200 userInfo:details];
      return NO;
    }
    return YES;
  }
  </code></pre>
  
  <p>by running 'analyze' in Xcode I get the famous 'potential null dereference' when creating error. While the compiler is not giving any alert, and the code has always worked.
  This could be a question too, why the compiler doesn't warn me about that ? </p>
  
  <p>But coming to the code, I perfectly know the solution, which is to check if (error != nil), but I am quite lost at this.
  The question start at the beginning, at the meaning of NSError *_autoreleasing* , why the surrounding star ? Which should be a pointer to a pointer ?</p>
  
  <p>Supposing I would like to call the validateForInsert: by myself, how can I build an *_autoreleasing* object ?</p>
  
  <p>The following question, I suppose is related to the question above: if I am building the *error from scratch, why am I suppose to check if nil first ?</p>
  
  <p>Last but not least, the code works fine, the errors get intercepted, could you please spot a case that can have it fail or crash ? As I said I am using CoreData, a generic example would be fine, but another related to CoreData is appreciated.</p>
  
  <p>thanks</p>