Différence en boucles if et exceptions

Bonjour

De profil profil ingénieur système Linux, je me remet doucement au dev POO (déjà abordé pendamt mes études) et je me repose la même question en évoluant sur Python, à savoir la difféence entre les boucles conditionnelles (genre if then ) et les exceptions (qui m'ont l'air de if évolués, je me trompe?).

En effet. j'ai toujours beaucoup de mal à cerner comment marchent les exceptions (leur principe....)

quelqu'un peut-il m'aider?

merci

kondor76

Salut

Tu peux regarder ici: https://www.developpez.net/forums/d1...on-permission/

Salut,

Effectivement, la philosophie de Python c'est de demander pardon plutôt que la permission. Mais cela ne veut pas dire qu'il est préférable de faire ceci:

Code:

---

1 2 3 4

try: x = a / c except ZeroDivisionError as e: # quelque chose

---

à

Code:

---

1 2 3 4

if c != 0: x = a / c else: # quelque chose

---

J

bonjour

Je dirais que surtout une exception remonte le code, elle est propagée au parent
Rien ne nous oblige à la relever à l'instant T

Sans exception, on se retrouve avec un code du type Go/Rust ou il faut retourner (en plus) un code erreur pour chaque fonction :roll:

Par exemple si on utilise une librairie, sans exceptions, on ne serait pas comment est gérée une erreur : la fonction retourne quoi ? une valeur par défaut, null ... du coup on a aucune lecture sur le problème et un retour "null" est-il une erreur ou une valeur probable ???
Alors qu'avec un

Code:

---

1 2 3

try: utils.SaveMyWork(filename, datas) except ...:

---

j'ai la possibilité de voir un problème de droits sur les fichiers ou un nom de fichier invalide et donc de gérer le problème au niveau le plus souhaitable pour moi - par exemple, à ce niveau je vais pouvoir afficher une fenêtre popup alors que c'est impensable dans la fonction

De plus, ce n'est pas à une petite fonction d'interrompre le programme automatiquement, c'est au programme de faire un choix en fonction de l'erreur - donc on déclenche des exceptions dans les fonctions et la gestion est reportée à l'appelant

Bonjour

Citation:

---

Envoyé par kondor76

boucles conditionnelles (genre if then )

---

Ben déjà tu éviteras de parler de "boucle if" si tu veux pas passer pour un gros nul tout ingénieur Linux de profil que tu es.

Citation:

---

Envoyé par kondor76

En effet. j'ai toujours beaucoup de mal à cerner comment marchent les exceptions (leur principe....)

---

Une exception c'est quelque chose d'exceptionnel. Donc déjà dans la philosophie, ce n'est pas la même chose qu'un choix X ou Y en fonction des circonstances.

De plus une exception ne se traite pas forcément au moment où elle se produit. Elle peut se produire dans la fonctionX et remonter la pile des appels pour être traitée dans la fonctionY 5 niveaux au dessus.

Hello

Merci pour vos réponse,

Alors d'après vos post j'ai l'impression que les exception ont l'air d'avoir un format pré-défini, surtout ou niveau du except, je me trompe?

par exemple ZeroDivisionError......

Merci

kondor76

Ce sont des objets effectivement déjà définis. C'est normal. Si Python doit les invoquer il faut qu'il les connaisse.
Elles se déploient en arbre depuis une racine "BaseException" mais généralement on ne monte pas aussi haut car ça englobe aussi les exceptions systèmes comme le KeyboardInterrupt (ctrl-c) donc si on veut monter au plus haut des exceptions de programmation on se contente de "Exception" qui est une des premières sous-branches.
Le ZeroDivisionError dont tu parles fait partie de la branche "ArithmeticError". Ca signifie que si tu attrappes cet "ArithmeticError" tu attrapperas aussi tout ce qui est en dessous comme le ZeroDivisionError.
Tu peux aussi te créer les tiennes que tu pourras faire hériter des officielles.

Et on peut créer ces propres exception fonctionnelles (au niveau de l'application)
SoldeNegatifException, LoginObligatoireException, AdminOnlyException, PourAdulteException, ConfigBadFormat , ...
On déclenche ces exceptions après in "if" mais aussi après avoir intercepté une exception bas niveau

Citation:

---

En effet. j'ai toujours beaucoup de mal à cerner comment marchent les exceptions (leur principe....)

---

Ce qui est important est de savoir quand utiliser les exceptions ou quand utiliser les conditions.

La question qu'il faut/faudrait toujours se poser, c'est qu'est-ce qui se passe au cas où... ?

Soit j'arrête le programme
Soit je continue en modifiant ce qu'il faut
Soit je fais l'un ou l'autre ci-dessus selon certaines conditions
Soit ...

Bref comment doit réagir le programme ? C'est un besoin conceptuel.

Quand l'erreur n'est pas grave, on peut utiliser un système de log qui prévient d'un petit dysfonctionnement non bloquant, mais qu'il faudra remédier un jour ou l'autre (ce n'est pas une urgence).

Il faut donc se poser les bonnes questions et souvent les réponses sont apportées par le métier, qui définit les règles (cahier des charges, ateliers, ...)

La bonne réponse à ta question n'existe pas, en terme général, c'est du cas par cas !

Bonjour

Pour moi, le "if then else" fait partie du déroulement normal du programme, mais le "try...except" représente une rupture dans ce déroulement, correspondant à un évènement anormal (et en principe rare).

Dans certains cas on pourrait utiliser "try...except" dans le déroulement normal. Par exemple, la méthode .index(...) d'une liste déclenche une exception "ValueError" si la valeur cherchée ne s'y trouve pas, et on pourrait donc l'utiliser pour tester cette possibilité. Mais j'en reste au principe ci-dessus: je n'utilise try...except que pour gérer quelque chose d'anormal.

A un moment donné, j'ai voulu détecter si un truc était itérable (listes, tuples, etc). Mais je ne pouvais pas faire un if classique style isinstance(truc, (list, tuple, dict)) car il y a des tas de trucs itérables (OrderedDict, NamedTuple) et même des trucs qui peuvent en hériter sans que je le sache.
Je me suis donc servi du try/except.

Code:

---

1 2 3 4 5 6

try: iter(x) except TypeError: # Pas itérable else: # Itérable

---

On peut aussi s'en servir comme contrôle de saisie

Code:

---

1 2 3 4

try: rep=int(input("Entrez un nombre")) except ValueErrror: print("Mauvaise saisie !!!")

---

Toujours cette histoire de pardon/permission souvent plus facile à implémenter qu'un if...

Salut,

Pour voir les choses un peu différemment, boucles et conditions permettent d'écrire une "fonctionnalité"...

Exemple définir une variable a en fonction de la valeur de n peut s'écrire:

Code:

---

1 2 3 4

if n < 10: a = 1 else: a = 0

---

mais on peut pousser ces instructions dans une fonction:

Code:

---

1 2 3 4 5 6

def f(n): if n < 10: a = 1 else: a = 0 return a

---

Dans ce cas, définir la variable a se fera via a = f(n).

Tout ce qu'on a besoin de savoir de la fonction se résume à sa description: retourne 1 si n < 10, 0 sinon. Les instructions que f va dérouler pour retourner ce résultat n'ont aucune importance (tant qu'elle fait le job), elles sont "cachées". La fonction f pourrait même être sortie d'une bibliothèque écrite dans un autre langage.

En écrivant a = f(n) on invente une nouvelle relation que l'on traduit parfois par une hiérarchie appelant/appelée, client/service,... qui sort complètement de la séquence d'instructions basiques construite avec boucles et condition...

Et on se retrouve aussi avec un "aléa" que faire si la fonction "f" ne peut pas réaliser le boulot qu'on lui demande? On a besoin d'autre chose qui signale que la fonction/opération n'a pas pu se dérouler normalement.

Avant l'invention des exceptions, la fonction f pouvait retourner un "status" rendant compte de sa bonne exécution: le résultat était à récupérer dans une variable passée par référence. C'est encore cette mécanique là qui est utilisée pour les appels systèmes.

Son principal défaut étant que si le programmeur oublie de tester le status de retour et récupère un résultat invalide, le code fera ce qu'il pourra jusqu'à ce qu'il plante bien après de la cause de l'erreur...

Les exceptions, c'est imparable soit on l'attrape (avec un try...except) et on la gère, soit le programme s'arrête. De plus une exception pourra remonter de informations qui permettront d'avoir une idée de la cause et de corriger le problème.

- W