Quel est l'intérêt de NSAssert, en fait?

Je dois poser cette question, car: La seule chose que je reconnais, c'est que si l'assertion échoue, l'application plante. Est-ce la raison pour laquelle utiliser NSAssert? Ou quel est l'avantage de celui-ci? Et est-il juste de mettre un NSAssert juste au-dessus de toute hypothèse que je fais dans le code, comme une fonction qui ne devrait jamais recevoir un -1 comme paramètre mais peut-être -0,9 ou -1,1?

Assert, c'est s'assurer qu'une valeur est ce qu'elle est censée être. Si une assertion échoue, cela signifie que quelque chose s'est mal passé et que l'application se ferme. Une raison d'utiliser assert serait si vous avez une fonction qui ne se comportera pas ou qui créera de très mauvais effets secondaires si l'un des paramètres qui lui sont passés n'est pas exactement une valeur (ou une plage de valeurs), vous pouvez mettre une assertion à faire Assurez-vous que cette valeur est ce que vous attendez d'elle, et si ce n'est pas le cas, quelque chose ne va vraiment pas et l'application se ferme. Assert peut être très utile pour le débogage / les tests unitaires, et aussi lorsque vous fournissez des frameworks pour empêcher les utilisateurs de faire des choses «mauvaises».

Je ne peux pas vraiment parler à NSAssert, mais j'imagine que cela fonctionne de manière similaire à assert () de C.

assert () est utilisé pour appliquer un contrat sémantique dans votre code. Qu'est-ce que cela signifie, demandez-vous?

Eh bien, c'est comme vous l'avez dit: si vous avez une fonction qui ne devrait jamais recevoir de -1, vous pouvez demander à assert () d'appliquer cela:

void gimme_positive_ints (int i) {
  assert (i> 0);
}

Et maintenant, vous verrez quelque chose comme ça dans le journal des erreurs (ou STDERR):

Échec de l'assertion i> 0: fichier example.c, ligne 2

Ainsi, non seulement il protège contre les entrées potentiellement mauvaises, mais il les enregistre de manière standard et utile.

Oh, et au moins en C, assert () était une macro, vous pouvez donc redéfinir assert () comme un no-op dans votre code de version. Je ne sais pas si c'est le cas avec NSAssert (ou même assert () plus), mais c'était assez utile de compiler ces vérifications.

NSAssertvous donne plus que simplement planter l'application. Il vous indique la classe, la méthode et la ligne où l'assertion s'est produite. Toutes les assertions peuvent également être facilement désactivées à l'aide de NS_BLOCK_ASSERTIONS. Le rendant ainsi plus adapté au débogage. D'un autre côté, lancer un NSExceptionne fait que planter l'application. Il n'indique pas non plus l'emplacement de l'exception et ne peut pas non plus être désactivé si simplement. Voyez la différence dans les images ci-dessous.

L'application se bloque car une assertion déclenche également une exception, comme l' indique la documentation NSAssert :

Lorsqu'il est appelé, un gestionnaire d'assertions imprime un message d'erreur qui inclut la méthode et les noms de classe (ou le nom de la fonction). Il déclenche ensuite une exception NSInternalInconsistencyException.

NSAssert:

NSException:

En dehors de ce que tout le monde a dit ci-dessus, le comportement par défaut de NSAssert()(contrairement à C assert()) est de lancer une exception, que vous pouvez attraper et gérer. Par exemple, Xcode fait cela.

Juste pour clarifier, comme quelqu'un l'a mentionné mais pas complètement expliqué, la raison d'avoir et d'utiliser des assertions au lieu de simplement créer du code personnalisé (faire des ifs et lever une exception pour de mauvaises données, par exemple) est que les assertions DEVRAIENT être désactivées pour les applications de production.

Lors du développement et du débogage, les assertions sont activées pour vous permettre de détecter les erreurs. Le programme s'arrête lorsqu'une assertion est évaluée comme fausse. Mais, lors de la compilation pour la production, le compilateur omet le code d'assertion et RENDENT VOTRE PROGRAMME PLUS RAPIDE. D'ici là, j'espère que vous avez corrigé tous les bogues. Dans le cas où votre programme a encore des bogues en production (lorsque les assertions sont désactivées et que le programme «saute» les assertions), votre programme finira probablement par planter à un autre moment.

De l'aide de NSAssert: "Les assertions sont désactivées si la macro de préprocesseur NS_BLOCK_ASSERTIONS est définie." Donc, mettez simplement la macro dans votre cible de distribution [uniquement].

NSAssert(et son équivalent stdlib assert) sont de détecter les erreurs de programmation lors du développement. Vous ne devriez jamais avoir une assertion qui échoue dans une application de production (publiée). Vous pouvez donc affirmer que vous ne passez jamais un nombre négatif à une méthode qui nécessite un argument positif. Si l'assertion échoue pendant le test, vous avez un bogue. Si, cependant, la valeur transmise est entrée par l'utilisateur, vous devez valider correctement l'entrée plutôt que de vous fier à l'assertion en production (vous pouvez définir un #define pour les versions de version qui désactive NSAssert*.

Les assertions sont couramment utilisées pour imposer l'utilisation prévue d'une méthode ou d'un élément de logique particulier. Supposons que vous écriviez une méthode qui calcule la somme de deux entiers supérieurs à zéro. Afin de vous assurer que la méthode a toujours été utilisée comme prévu, vous mettriez probablement une affirmation qui teste cette condition.

Réponse courte: Ils imposent que votre code soit utilisé uniquement comme prévu.

Il vaut la peine de souligner qu'en dehors de la vérification de l'exécution, la programmation d'assert est une fonction importante utilisée lorsque vous concevez votre code par contrat.

Vous trouverez ci-dessous plus d'informations sur l'assertion et la conception par contrat:

Assertion (développement logiciel)

Conception par contrat

Programmation avec assertions

Conception par contrat, par exemple [Broché]

Pour répondre pleinement à sa question, le but de tout type d'affirmation est d'aider au débogage. Il est plus intéressant de détecter les erreurs à leur source, que de les détecter dans le débogueur lorsqu'elles provoquent des plantages.

Par exemple, vous pouvez transmettre une valeur à une fonction qui attend des valeurs dans une certaine plage. La fonction peut stocker la valeur pour une utilisation ultérieure et, lors d'une utilisation ultérieure, l'application se bloque. La pile d'appels vue dans ce scénario n'afficherait pas la source de la valeur incorrecte. Il est préférable d'attraper la mauvaise valeur au fur et à mesure qu'elle entre pour savoir qui passe la mauvaise valeur et pourquoi.

NSAssertfaire planter l'application lorsqu'elle correspond à la condition. S'il ne correspond pas à la condition, les instructions suivantes seront exécutées. Recherchez l'EX ci-dessous:

Je viens de créer une application pour tester quelle est la tâche de NSAssert:

    - (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    [self testingFunction:2];
}

-(void)testingFunction: (int)anNum{
    // if anNum < 2 -> the app will crash
    // and the NSLog statement will not execute
    // that mean you cannot see the string: "This statement will execute when anNum < 2"
    // into the log console window of Xcode
    NSAssert(anNum >= 2, @"number you enter less than 2");
    // If anNum >= 2 -> the app will not crash and the below 
    // statement will execute
    NSLog(@"This statement will execute when anNum < 2");
}

dans mon code, l'application ne plantera pas.Et le cas de test est:

• anNum > = 2 -> L'application ne plantera pas et vous pouvez voir la chaîne du journal: "Cette instruction s'exécutera quand unNum <2" dans la fenêtre de la console du journal outPut
• anNum <2 -> L'application plantera et vous ne pouvez pas voir la chaîne de journal: "Cette instruction s'exécutera quand anNum <2"