* Rien faire (laisser la responsabilité à l'utilisateur).
* Faire paniquer le programme (il plante plus ou moins violemment).
* Utiliser des codes d'erreurs.
## La panique
* En C on a les `assert()` pour faire paniquer un programme.
# Assertions (1/3)
```C
#include <assert.h>
void assert(int expression);
```
## Qu'est-ce donc?
- Macro permettant de tester une condition lors de l'exécution d'un programme:
- Si `expression == 0`{.C} (condition fausse), `assert()`{.C} affiche un message d'erreur sur `stderr`{.C} et termine l'exécution du programme.
- Sinon l'exécution se poursuit normalement.
- Peuvent être désactivés avec `-DNDEBUG` (équivalent à `#define
NDEBUG`)
## À quoi ça sert?
- Permet de réaliser des tests unitaires.
- Permet de tester des conditions catastrophiques d'un programme.
-**Ne permet pas** de gérer les erreurs.
# Assertions (2/3)
<!-- \footnotesize -->
## Exemple
```C
#include <assert.h>
void stack_push(stack *s, int val) {
assert(s->top < MAX_CAPACITY - 1);
stack->top += 1;
stack->data[stack->top] = val;
}
int stack_pop(stack *s) {
assert(s->top >= 0);
stack->top -= 1;
return stack->data[stack->top+1];
}
int stack_peek(stack *s) {
assert(s->top >= 0);
return stack->data[stack->top];
}
```
# Assertions (3/3)
## Cas typiques d'utilisation
- Vérification de la validité des pointeurs (typiquement `!= NULL`{.C}).
- Vérification du domaine des indices (dépassement de tableau).
## Bug vs erreur de *runtime*
- Les assertions sont là pour détecter les bugs (erreurs d'implémentation).
- Les assertions ne sont pas là pour gérer les problèmes externes au programme (allocation mémoire qui échoue, mauvais paramètre d'entrée passé par l'utilisateur, ...).
. . .
- Mais peuvent être pratiques quand même pour ça...
