Gestion des exceptions de sortie/production iPhone

Question

En avance, veuillez excuser mon manque de compréhension des meilleures pratiques iPhone/Objective-C; Je viens d'un arrière-plan .NET/C#.

Bien que j'ai lu beaucoup de messages concernant la gestion des exceptions pour l'iPhone, je ne suis toujours pas clair sur ce que font la plupart des gens pour le code de production. En outre, je n'ai pas été en mesure de trouver des applications open source avec la gestion des erreurs que je m'attendais normalement. Voici mes questions:

1) Si un résultat imprévu peut provoquer l'échec de l'application, lèveriez-vous une exception ou attendriez-vous qu'elle échoue plus tard? Par exemple,

if (![fileManager createDirectoryAtPath: myNewDir 
    withIntermediateDirectories: YES 
    attributes: nil 
    error: &myError]) { 

    // My app shouldn't continue. Should I raise an exception? 
    // Or should I just log it and then wait for it to crash later? 
} 

2) Validez-vous les paramètres? Par exemple, en C#, je vérifie habituellement null et, si nécessaire, lance une ArgumentNullException.

3) Lorsqu'une application tombe en panne, est-ce que les informations de plantage sont consignées automatiquement ou dois-je définir le gestionnaire d'exceptions non gérées? Puis-je montrer un UIAlertView dans cette méthode pour informer l'utilisateur que quelque chose de mal est arrivé, au lieu de faire disparaître l'application? (Si c'est le cas, je ne pourrais pas le faire fonctionner.)

4) Et enfin, pourquoi est-ce que je ne vois personne utiliser @ try/@ catch/@ finalement? Il est largement utilisé en C#, mais je n'ai pas trouvé d'applications open source l'utilisant. (Peut-être que je ne fais que regarder les mauvaises applications.)

Answer 1

Ad 1. L'exemple que vous donnez est un exemple assez classique de quand on devrait utiliser une "exception vérifiée" en Java. L'appelant de la méthode doit être préparé, que l'appel peut échouer pour des raisons qui sont en dehors de ce qu'il peut contrôler. En particulier, dans l'exemple donné, je accueillerais l'erreur descripteur objet permet de se propager à l'appelant:

- (BOOL) prepareDirectories: (NSString*) path error: (NSError**) location { 

    if(![fileManager createDirectoryAtPath: path 
         withIntermediateDirectories: YES 
         attributes: nil 
         error: location]) { 

     return NO; 
    } 

    // ... additional set-up here 
    return YES; 
} 

Si l'erreur est vraiment pas recouvrable, vous pouvez soulever en fait une exception, mais qui aussi renoncer toute chance d'afficher un message d'erreur approprié à l'utilisateur de votre application.

Ad 2. Oui, la validation des paramètres est définitivement quelque chose que vous devriez faire. Et lever une exception pour nil s inattendu est tout à fait approprié. Un mauvais paramètre est une "erreur du programmeur" et vous ne pouvez pas garantir que le programme est toujours dans un état cohérent. Par exemple, NSArray déclenche une exception si vous tentez d'obtenir un élément à l'aide d'un index inexistant. Ad 3. Lorsque l'application se bloque en raison d'une exception non interceptée, le fait est enregistré automatiquement. Vous pouvez attraper l'exception si vous voulez vraiment afficher un message d'erreur. Cependant, l'application est susceptible d'être dans un état incohérent, et ne devrait pas être autorisé à continuer, donc simplement le laisser tomber, semble la meilleure solution ici.

Ad 4. ​​Je ne sais pas.

Answer 2

1. Dans le cas spécifique que vous mentionnez, vous devez présenter une notification à l'utilisateur sur ce qui vient de se passer avec des instructions sur la façon de résoudre la situation. Sauf dans des circonstances extrêmes, votre application ne devrait pas quitter. Vous devriez laisser l'utilisateur réparer ce qui ne va pas, puis réessayer.
2. La validation du paramètre dépend de nombreux facteurs. Une chose à garder à l'esprit est que dans Obj-C, il est parfaitement valide d'envoyer des messages à nil (rien ne se passe si vous le faites), donc dans beaucoup de situations, vous n'avez pas besoin de vérifier pour rien. Si je suis dans une classe de modèle, je valide toujours les paramètres dans les méthodes. Si je ne suis pas je ne valide presque jamais rien, le contrôle de type est assez bon.
3. Certaines informations doivent être enregistrées, mais il est toujours utile de consigner des informations plus spécifiques à votre situation. Idéalement, vous ne devriez jamais atteindre l'état d'exception non gérée.
4. Les classes de cacao jettent rarement des exceptions pour des raisons environnementales, elles sont presque toujours parce que vous avez fait quelque chose de mal. Par exemple, vous ne placez généralement pas de bloc @ try/@ catch autour de [NSString stringWithString:] car la seule façon de lancer une exception est d'essayer de passer le nil. Assurez-vous que vous ne passez pas nil et vous ne devrez pas vous soucier d'attraper des exceptions. Lorsqu'une méthode peut échouer à cause de quelque chose hors de votre contrôle, elle communique généralement via une erreur NSError. Voir la méthode - (BOOL)save:(NSError **)error de NSManagedObjectContext par exemple.