Next: Épuisement de ressources Up: Situations exceptionnelles Previous: Situations exceptionnelles
La première catégorie contient les situations exceptionnelles de type échecs. Il s'agit d'une erreur de programmation. Typiquement, des préconditions (voir section 27.3) ne sont pas respectées, à savoir que l'appelant d'une fonction lui a passé des arguments non conformes aux exigences de celle-ci. C'est la responsabilité du programmeur de vérifier les préconditions d'une fonction avant de l'appeler.
Lorsque le programme est en situation d'échec, son état est inconnu. Le programmeur n'a pas prévu la situation. On ne peut donc pas savoir ce que le programme est en train de faire. Par exemple, il se peut que le programme soit en train d'écraser les fichiers de l'utilisateur final. La seule action raisonnable en cas d'échec est d'arrêter l'exécution du programme le plus vite possible avec un message d'erreur destiné au programmeur et non à l'utilisateur.
Certaines situations d'échec sont relativement faciles à détecter pour le programmeur. Si les arguments d'une fonction doivent respecter des préconditions facilement vérifiables, il est conseillé de les vérifier. La façon la plus simple est d'utiliser la macro assert. Dans sa version simple, elle accepte une expression dont la valeur doit être vrai. Si ce n'est pas le cas, une erreur est signalée. Exemple :
Parfois, la fonction qui détecte une situation exceptionnelle n'a pas les moyens de déterminer si cette situation est vraiment un échec. Un exemple classique est l'ouverture d'un fichier. Si le fichier n'existe pas et si c'est un fichier faisant partie de l'application (par exemple un fichier contenant des icônes), il s'agit d'un échec. Si, par contre, il s'agit d'un fichier dont l'ouverture a été demandée par l'utilisateur, c'est une situation que le programme doit traiter d'une manière acceptable pour l'utilisateur.
Dans ces situations, l'utilisation de la macro assert n'est pas la bonne solution.
Irene DURAND