gestion des erreur et exception avec try except : comment gérer deux types?

Bonjour
je découvre la gestion des erreur et exception avec try except.

comment faire pour gérer plusieurs erreurs qui peuvent survenir dans un try?

par exemple
j'ai le cas simple:

Code:

---

1 2 3 4 5 6

while True: try: x = int(input("saisir un nb : ")) break # permet de sortir de la boucle while si aucnue erreur n'est générée except: print("ce n'est pas un nb...")

---

ce code genèrre une xception dès qu'il y a une erreur (quel que soit le type), ici je comprends que ce sera forcément le type valueError



j'ai cet autre cas simple

Code:

---

1 2 3 4 5 6 7

try: x = int(input("saisir un nb: ")) result = 10/x print (result)   except ZeroDivisionError: print("probleme de division")

---

si on entre un nombre différent de 0: OK
si on entre 0, on génère l'erreur ZeroDivisionError qui correspond à l'exception, on entre dans l'except
si on entre autre chose qqu'un chiffre, on génère une erreur qui n'est psa ZeroDivisionError (valueError), donc on n'entre pas dans l'except

maintenant si je veux gérer deux erreur : valueError et ZeroDivisionError
comment je fais pour préciser ces deux types dans exception?

merci

Bonjour

Citation:

---

Envoyé par sqlbeginner

maintenant si je veux gérer deux erreur : valueError et ZeroDivisionError
comment je fais pour préciser ces deux types dans exception?

---

Code:

---

1 2 3 4 5 6 7 8

try: x = int(input("saisir un nb: ")) result = 10/x print (result) except ZeroDivisionError: print("probleme de division par zéro") except ValueDivisionError: print("probleme de valeur")

---

Code:

---

1 2 3 4 5 6

try: x = int(input("saisir un nb: ")) result = 10/x print (result) except (ZeroDivisionError, ValueError): print("probleme de division par zéro ou de valeur")

---

Mais généralement deux actions distinctes se gèrent de façon distincte...

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try: x = int(input("saisir un nb: ")) except ValueDivisionError: print("probleme de valeur") else: try: result = 10/x except ZeroDivisionError: print("probleme de division par zéro") else: print (result)

---

Après, si on peut éviter le try (plus gourmand)...

Code:

---

1 2 3 4 5 6 7 8 9 10

try: x = int(input("saisir un nb: ")) except ValueDivisionError: print("probleme de valeur") else: if x != 0: result = 10/x print (result) else: print("probleme de division par zéro")

---

... mais avant d'envisager ce dernier cas faut réfléchir au danger du TOCTOU bug...

Salut,

Citation:

---

Envoyé par sqlbeginner

maintenant si je veux gérer deux erreur : valueError et ZeroDivisionError
comment je fais pour préciser ces deux types dans exception?

---

Pour info, il y a un chapitre entier sur ce sujet dans le tutoriel livré avec le langage Python.

- W

Citation:

---

Envoyé par Sve@r

Bonjour


Après, si on peut éviter le try (plus gourmand)...

Code:

---

1 2 3 4 5 6 7 8 9 10

try: x = int(input("saisir un nb: ")) except ValueDivisionError: print("probleme de valeur") else: if x != 0: result = 10/x print (result) else: print("probleme de division par zéro")

---

... mais avant d'envisager ce dernier cas faut réfléchir au danger du TOCTOU bug...

---

le try n'est pas une bonne pratique?
il faut le limiter dans un script python?

Citation:

---

Envoyé par sqlbeginner

le try n'est pas une bonne pratique?
il faut le limiter dans un script python?

---

Ce n'est pas ce qu'à dit Sve@r.
Il a dit qu'il fallait faire attention à ne pas créer un bug de type Time-of-check to time-of-use (ou TOCTOU) dans la structure qu'il a montré.


Après les puriste me corrigeront si je dis une bêtise mais AMHA, une exception doit être être, comme son nom l'indique, exceptionnelle.
Ceci car un code placé dans un bloc try sera plus long à exécuter

Citation:

---

Envoyé par popo

près les puriste me corrigeront si je dis une bêtise mais AMHA, une exception doit être être, comme son nom l'indique, exceptionnelle.
Ceci car un code placé dans un bloc try sera plus long à exécuter

---

Je dirais çà autrement: un bloc try...except ne sera pas plus lent/long à exécuter tant qu'il n'y a pas d'exception à traiter <=> l'exception doit être exceptionnelle.... mais c'est une fonctionnalité récente:

Citation:

---

Envoyé par 3.11 release notes

“Zero-cost” exceptions are implemented, eliminating the cost of try statements when no exception is raised. (Contributed by Mark Shannon in bpo-40222.)

---

avant 3.11 (que je n'ai pas testé) ça coute quand même un peu.

- W

Citation:

---

Envoyé par sqlbeginner

le try n'est pas une bonne pratique?

---

Voilà, deux autres intervenants de talents ont répondu. Je vais rajouter ma propre réponse: ce n'est pas une bonne pratique quand on peut (sans risque) faire autrement.
Dit autrement: si tu ne maîtrises pas ton environnement et ce qui s'y passe (une saisie comme tu l'as fait, ou l'accès à un fichier qui peut disparaitre, ou autre), alors try/except (je tente et je gère si ça n'a pas pu se faire). Mais utiliser try/except pour évaluer une situation que tu maîtrises et qui ne changera pas entre temps (ici une variable qui peut valoir zéro) c'est non. Ce n'est pas interdit mais les autres solutions sont plus rapides.

bonjour

C'est une très bonne pratique, mais il faut savoir quand/comment l'utiliser.

On a tous commencé avec ton exemple mais il n'est pas représentatif de la puissance des exceptions.

première chose : On n'est pas obligé de lever une exception immédiatement comme ton exemple (ici, un if peut parfois être aussi efficace)
une exception va être transmise au code en amont et ici, cela peut être très utile.

puisque ton peuso est SQL...

Code:

---

1 2 3 4

try: sql_sauvegarde_tout_transaction(x,y,z) # ma fonction complexe qui elle, ne lève aucune exception except SqlException: rollback()

---

Une exception n'est pas obligatoirement une erreur, parfois, on peut utiliser ce système pour donner des infos en amont (dans le code).
Il ne faut pas oublier que l'on peut aussi lancer des exceptions ! Et, en plus, nous pouvons créer nos propres Exceptions

Code:

---

if len(sys.argv) <1: raise valueError("Il faut au moins passer un paramètre")

---

# Créer une exception "ExceptionMoinsDe18Ans"

Code:

---

1 2 3 4 5 6

try: datas = saisie_utilisateur() # exception créée dans une "sous" fonction de celle ci except ExceptionMoinsDe18Ans: print("Attention, il faut en plus ....") faire_une_chose_particulière(datas) # peut-être plus simple que de créer 36 "if datas.age <18" dans notre application (pour une, NON)

---

Même chose, avec la création de nos propres exceptions Alerte...Critique (exemple trop basique ici pour être forcément pertinent, mais donne bien l'idée)
Reste à voir si c'est bien à prendre_des_mesures() ou une de ces sous-fonctions de déterminer ce qui est une Alerte ou une erreur ...

Code:

---

1 2 3 4 5 6

try: datas = prendre_des_mesures() except TemperatureWarm as alerte: log(temp, alerte) except TemperatureCritique: raise

---

------------

Plus proche de la question originelle, depuis python 3.11 nous avons en plus la pep 654 : pas pour intercepter, mais pour déclencher un groupe d'exceptions.