Introduction aux situations exceptionnelles en Python

Dans cette section, seront examinées les situations exceptionnelles en Python. Pour commencer, il faut comprendre ce qu'elles représentent.

Lors de l'écriture d'un programme, le développeur suppose implicitement que tous les mécanismes techniques et logiciels utilisés fonctionneront correctement.

Cependant, ce n'est pas toujours le cas. Lors du transfert de données via le réseau, la connexion est interrompue et les données nous parviennent dans un format incorrect, ou ne parviennent pas du tout. Lors de l'écriture d'un fichier, il s'avère que l'espace qui nous était alloué sur le disque dur est épuisé, et le fichier ne peut pas être enregistré. Lors de la lecture d'un fichier, il s'avère que ce fichier n'existe pas et que nous n'avons nulle part où lire. Lors de l'impression de données sur l'imprimante, le câble reliant l'imprimante et l'ordinateur se rompt.

Toutes les situations décrites ont une essence commune : une défaillance se produit, ce qui conduit à l'impossibilité ou à l'absence de sens de terminer l'opération planifiée.

Il y a aussi des situations où une erreur se produit, qui n'est pas une défaillance. Par exemple, vous demandez à l'utilisateur son email, et il entre un email dans un format incorrect. Il est clair que notre programme ne peut pas continue à traiter l'email, car il n'est pas correct. Mais, néanmoins, ce n'est pas une situation exceptionnelle. Notre programme peut lui-même corriger la situation : il affichera un message d'erreur et l'utilisateur répétera sa saisie.

En réalité, la différence entre une défaillance et une non-défaillance est assez floue. Un événement qu'un programme peut interpréter comme une situation exceptionnelle, un autre programme peut l'interpréter comme une erreur avec laquelle il peut composer.

Le critère ici est le suivant : si lors de l'apparition d'un problème votre programme peut continuer à exécuter ce pour quoi il est conçu, alors ce n'est pas une situation exceptionnelle, mais si il ne le peut pas - alors oui, c'est une exception.

Par exemple, nous avons un programme qui doit demander l'email de l'utilisateur. Si l'utilisateur a entré un email dans un format incorrect - ce n'est pas une défaillance. C'est un problème attendu et notre programme demandera à l'utilisateur son email autant de fois qu'il le faudra jusqu'à ce qu'il l'entre correctement.

Supposons que notre programme, qui demande l'email, doive également envoyer cet email correct via Internet. Il s'avère alors qu'Internet ne fonctionne pas. Là, c'est déjà un problème : le programme ne pourra en aucun cas envoyer les données via Internet si Internet ne fonctionne pas. Le programme peut, néanmoins, poursuivre son exécution : il peut afficher des informations sur le problème, réessayer l'envoi après un certain temps, et ainsi de suite. Mais ces actions ne sont plus tout à fait ce pour quoi le programme était conçu, car l'action principale - l'envoi de l'email - le programme ne pourra pas la faire.

C'est pourquoi, très souvent, l'interprétation de ce qui sera considéré comme un comportement normal, et de ce qui sera considéré comme exceptionnel, dépend des tâches auxquelles le programmeur est confronté.