Corriger la structure pour vérifier les erreurs en utilisant NSError

Question

Je suis en train de coder différentes routines et je fais de mon mieux pour le garder net et refactorisé.

Méthodes Je crée commencent à ressembler à ce code:

-(IBAction)buttonPress:(id)sender { 
    // Create Document Shopping List with this document 
    [self doSomething:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 

    [self doSomethingElse:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 

    [self doYetSomethingElse:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 
} 

J'adore NSError, mais cela semble être un moyen terriblement maladroit de traiter toutes mes erreurs.

Quelques réflexions que j'ai eu sur les façons alternatives:

a) la vérification d'erreur pourrait être intégrée dans les méthodes DoSomething, doSomethingElse etc, mais je ne serais pas en mesure de quitter la méthode de presse de bouton sans faire une sorte de vérification de la valeur de retour, ce qui me ramènerait à une structure similaire.

b) Je pourrais configurer l'erreur NSError comme étant la valeur clé observée, mais quelque chose à ce sujet me semble profondément erroné. Je suis très conscient des possibilités d'abus avec le KVO, alors j'essaie de tout faire sans lui autant que possible.

Sûrement il me manque quelque chose de vraiment basique ici? Y a-t-il un modèle qui peut m'aider? Ou est-ce que cette structure est OK?

Answer 1

Je pense qu'aucune des réponses présentées ici ne prend en compte les pratiques recommandées par Apple.

Fondamentalement, vous ne devriez jamais vérifier l'objet NSError pour déterminer s'il y avait un problème. Vous vérifiez s'il y a eu un problème en vérifiant la valeur retournée par la méthode qui prend un pointeur vers un pointeur vers un NSError.

De the Apple documentation:

Important succès ou l'échec est indiquée par la valeur de retour de la méthode . Bien que les méthodes de cacao qui renvoient indirectement des objets d'erreur dans le domaine d'erreur Cocoa sont garantis pour renvoyer ces objets si la méthode indique l'échec par directement le retour nil ou NO, vous devriez toujours vérifier que la valeur de retour est nil ou NO avant de tenter de faire quelque chose avec l'objet NSError.

Answer 2

Remarque: Lorsque j'ai publié ce message, je ne connaissais aucun débat sur les exceptions MacOS/Cocoa. Gardez cela à l'esprit lorsque vous considérez cette réponse. Pourquoi ne pas utiliser exceptions à la place? Cela vous permettra de vous passer du paramètre error sur vos méthodes et de gérer vos erreurs en un seul endroit.

-(IBAction)buttonPress:(id)sender { 
    // Create Document Shopping List with this document 
    @try { 
     [self doSomething]; 
     [self doSomethingElse]; 
     [self doYetSomethingElse]; 
    } @catch (NSException* e) { 
     [NSApp presentException:e]; 
    } 
    return nil; 
} 

Vous aurez bien sûr besoin de lever des exceptions selon les besoins à partir de vos méthodes de doXXXX:

NSException* e = [NSException exceptionWithName:@"MyException" 
             reason:@"Something bad happened" 
             userInfo:nil]; 
@throw e; 

Answer 3

Je pense que la vraie question est de savoir combien vous avez besoin granularité dans votre gestion des erreurs. Votre code est fondamentalement correct - mais vous pouvez nettoyer les choses en vérifiant les erreurs moins fréquemment, ou en utilisant une approche fourre-tout comme teabot mentionné dans sa réponse avec NSException. Beaucoup de fonctions intégrées qui renvoient des erreurs (comme moveItemAtPath :) de NSFileManager renvoient un BOOL en plus de fournir un objet NSError - vous pouvez donc également utiliser des instructions if imbriquées si vous n'avez pas besoin des informations NSError.

Tout et tout cependant, il n'y a vraiment pas un excellent moyen de le faire. Si votre code est long, KVO pourrait être une bonne solution. Je n'ai jamais essayé pour une situation comme celle-ci, cependant.

Answer 4

L'essentiel de votre question est de savoir s'il existe des améliorations structurelles que vous pouvez apporter à la gestion des erreurs. Je pense donc, en introduisant essentiellement plus de couches d'imbrication, soit en extrayant plus de code dans des méthodes/fonctions séparées, soit en introduisant l'imbrication dans votre méthode d'échantillonnage de haut niveau. L'idée est la suivante: lorsque vous manipulez la plupart des erreurs, vous êtes probablement intéressé à effectuer une autre tâche ou à échouer et propager l'erreur dans la chaîne afin qu'un contrôleur responsable puisse transmettre l'erreur à l'utilisateur via UI.

En utilisant cette idée de « Propager ou la poignée », je réécris votre méthode d'échantillonnage comme ceci:

-(IBAction)buttonPress:(id)sender { 

    // Create Document Shopping List with this document 
    [self doSomething:&error];  
    if(error == nil) { 
     [self doSomethingElse:&error]; 
     if (error == nil) { 
      [self doYetSomethingElse:&error]; 
     } 
    } 

    if(error) { 
     [NSApp presentError:&error]; 
    }  
} 

Notez qu'il existe de bons arguments contre l'introduction trop d'imbrication dans une méthode particulière. L'imbrication de ce genre est essentiellement une courte alternative à l'extraction de méthodes. Il peut être plus logique, par exemple, que "doSomething:" appelle lui-même doSomethingElse :, qui appelle doYetSomethingElse: par exemple. Cela imposerait la même structure sur le code que le if-nest, mais serait sans doute plus maintenable. En outre, je ne suis pas un fan des déclarations de retour en ligne. Dans ce cas particulier, la méthode exemple n'appelle pas réellement une valeur de retour, mais si c'est le cas, je préfère définir une variable locale à la valeur renvoyée et retourner uniquement à la fin du contrôle de flux. Saut d'une fonction ou d'une méthode prématurément est un moyen sûr de rencontrer des bugs étranges, à mon humble avis.