EXC_BAD_ACCESS sur [erreur localiséeDescription];

Ce code trows un EXC_BAD_ACCESS:EXC_BAD_ACCESS sur [erreur localiséeDescription];

NSError* error; 
    if(![appdelegate.managedObjectContext countForFetchRequest:request error:&error]) { 
     DLog(@"Failed to save to data store: %@", [error localizedDescription]); 
     NSArray* detailedErrors = [[error userInfo] objectForKey:NSDetailedErrorsKey]; 
     if(detailedErrors != nil && [detailedErrors count] > 0) { 
      for(NSError* detailedError in detailedErrors) { 
       DLog(@" DetailedError: %@", [detailedError userInfo]); 
      } 
     } 
     else { 
      DLog(@" %@", [error userInfo]); 
     } 
    }

Source

2010-03-17 david

Vous pouvez essayer le [Clang Static Analyzer] (http://iphonedevelopment.blogspot.com/2009/02/clang-static-analyzer.html) ... Il est vraiment utile pour rechercher des fuites .. –

NSError * erreur = nul;

est correcte

Ce n'est pas vraiment une question. J'ai cherché ça et j'ai mis longtemps pour trouver la réponse alors voilà!

Source

2010-03-17 12:16:06 david

bien que cela saute le message d'erreur, mais (sans voir le reste du code) je pense que votre logique n'est pas vraiment correcte. Si l'erreur est nulle, l'envoi d'un message ne provoquera pas d'erreur, mais vous verrez probablement des messages faux dans le journal. –

@Victor Jalencas Mettre "erreur" à zéro est correct, mais je suis d'accord, en sautant NSLog()/DLog() au cas où "erreur" est nul est également nécessaire pour passer les messages de journal vides. –

Puisque vous ne demandez pas, je suppose que vous voulez savoir ce qui cause l'erreur dans le titre. Il me semble que votre requête a renvoyé 0 objets, et vous traitez cette condition comme s'il s'agissait d'une erreur alors qu'il n'y en avait aucune, et donc l'erreur n'a jamais été initialisée (elle n'a même pas été allouée).

Source

2010-03-17 12:18:57

EXC_BAD_ACCESS sur [erreur localiséeDescription];

Répondre

Questions connexes