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

Question

Je dois demander ça, parce que : La seule chose que je reconnaisse, c'est que si l'assertion échoue, l'application se plante. Est-ce la raison pour laquelle il faut utiliser NSAssert ? Ou quel est son autre avantage ? Et est-il correct de mettre une 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 recevoir un -0.9 ou -1.1 ?

Answer 1

L'affirmation consiste à s'assurer qu'une valeur est ce qu'elle est censée être. Si une assertion échoue, cela signifie que quelque chose a mal tourné et que l'application s'arrête. Une raison d'utiliser assert serait si vous avez une fonction qui ne se comportera pas ou créera de très mauvais effets secondaires si l'un des paramètres qui lui est passé n'est pas exactement une certaine valeur (ou une plage de valeurs), vous pouvez mettre une assert pour vous assurer que cette valeur est ce que vous attendez qu'elle soit, et si ce n'est pas le cas, quelque chose ne va vraiment pas, et donc l'application s'arrête. Les assertes peuvent être très utiles pour le débogage et les tests unitaires, mais aussi lorsque vous fournissez des cadres pour empêcher les utilisateurs de faire des choses "maléfiques".

Answer 2

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

assert() est utilisé pour faire respecter un contrat sémantique dans votre code. Vous vous demandez ce que cela signifie ?

Eh bien, c'est comme vous l'avez dit : si vous avez une fonction qui ne doit jamais recevoir un -1, vous pouvez demander à assert() de le faire respecter :

void gimme\_positive\_ints(int i) {
  assert(i > 0);
}

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

Assertion i > 0 failed: file example.c, line 2

Ainsi, non seulement il se protège contre les entrées potentiellement mauvaises, mais il les consigne d'une manière utile et standard.

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

Answer 3

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

Answer 4

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

Pendant le développement et le débogage, les alertes 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 permet en fait à votre programme de fonctionner plus rapidement. À ce moment-là, avec un peu de chance, vous avez corrigé tous les bogues. Au cas où votre programme aurait 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.

Extrait de l'aide de NSAssert : "Les assertions sont désactivées si la macro du préprocesseur NS_BLOCK_ASSERTIONS est définie." Donc, il suffit de mettre la macro dans votre cible de distribution [seulement].

Answer 5

NSAssert (et son équivalent stdlib assert ) servent à détecter les erreurs de programmation pendant le développement. Vous ne devriez jamais avoir une assertion qui échoue dans une application de production (publiée). Ainsi, vous pourriez affirmer que vous ne passez jamais un nombre négatif à une méthode qui requiert un argument positif. Si l'assertion échoue pendant les tests, vous avez un bogue. Si, cependant, la valeur qui est passée est entrée par l'utilisateur, vous devez faire une validation appropriée de l'entrée plutôt que de vous fier à l'assertion en production (vous pouvez définir un #define pour les builds de version qui désactive NSAssert* .