à propos des Exceptions

Bonjour,
Je pense que l'apprentissage de python passe aussi par la connaissance de ses exceptions.
La documentation et les tutoriels( du moins ceux que j'ai parcouru) se contentent de les lister.
Aussi, je me dis qu'il serait probablement intéressant/pédagogique/ludique/utile (?) de proposer un jeu consistant à les provoquer à la demande:
genre: écris un code provoquant l'exception MachinTruc
Étonnamment, je n'ai rien vu qui propose cette approche. (peut être n'ai-je pas bien cherché?)

Qu'en pensez-vous?
D'autre part, selon vous, quelles sont les exceptions de base à connaitre? (les plus rencontrées chez un débutant)
J'ai listé celles-ci:

Code:

---

1 2 3 4

errors = ['ZeroDivisionError', 'AttributeError', 'IndexError', 'NameError', 'ImportError', 'KeyboardInterrupt', 'RecursionError', 'StopIteration', 'SyntaxError', 'IndentationError', 'TypeError', 'UnboundLocalError', 'ValueError', 'KeyError']

---

Sinon si il y avait un niveau 'expert' au jeu:
Quelle exception y mettriez-vous? et quel code proposeriez-vous afin de les provoquer? (pour proposer une correction)

Sinon pour la structure de base du code (s'il y a un intérêt à l'écrire) je pensais à un truc du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

errors = ['ZeroDivisionError', 'AttributeError', 'IndexError', 'NameError', 'ImportError', 'KeyboardInterrupt', 'RecursionError', 'StopIteration', 'SyntaxError', 'IndentationError', 'TypeError', 'UnboundLocalError', 'ValueError', 'KeyError']   for excep in errors: print(f"Provoque l'exception {excep}") code = "" print("entre ton code:") for line_code in iter(input, ""): code += line_code + "\n"   try: exec(code) except eval(excep): if f"raise {excep}" in code: print('Tricheur raise est interdit!') else: print('bravo') else: print('perdu')

---

Je pourrais agrémenter d'effets visuels/sonores pour rendre la chose plus ludique...

édit: ajout test pour éviter l'usage de raise ...

Salut,

On rencontre les exceptions lorsqu'elles nous pètent à la gueule. On cherche à comprendre pourquoi en lisant la documentation.

Puis lorsqu'on a compris leur intérêt, on pourra fabriquer des fonctions qui lèvent une exception lorsqu'on leur passe des arguments invalides ou autre (une exception est levée lorsqu'une opération ne peut pas retourner à son appelant un résultat acceptable).

Je ne vois pas l'intérêt de simuler un tas d'exceptions (le boulot à faire est identique...) mais si on y tient:

Code:

---

1 2 3 4 5 6 7 8

>>> def f(e): ... raise e ... >>> f(ValueError) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in f ValueError

---

suffit.

- W

Salut !

Je ne sais pas si c'est correct, mais pour éviter l'eval() autant procéder ainsi :

Code:

---

1 2 3 4

errors = [ZeroDivisionError, AttributeError, IndexError, NameError, ImportError, KeyboardInterrupt, RecursionError, StopIteration, SyntaxError, IndentationError, TypeError, UnboundLocalError, ValueError, KeyError]

---

Non ?

Sinon aucune idée, FileNotFoundError n'est pas rare, par contre sûrement plus dur à soulever la FileExistsError, PermissionError, SyntaxWarning (???)... Cf. lien de Wiztiti !

Re,

Citation:

---

Envoyé par wiztricks

Je ne vois pas l'intérêt de simuler un tas d'exceptions (le boulot à faire est identique...)

---

J'y vois un intérêt pédagogique, mais si je suis le seul effectivement cela est sans intérêt :roll:

Citation:

---

Envoyé par wiztricks

mais si on y tient:

Code:

---

1 2 3 4 5 6 7 8

>>> def f(e): ... raise e ... >>> f(ValueError) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in f ValueError

---

suffit.

---

Je considère ça comme de la triche... Je pourrais facilement tester si le joueur utilise raise, auquel cas je le mets au coin avec un zéro pointé :lol:

Citation:

---

Envoyé par LeNarvalo

Je ne sais pas si c'est correct, mais pour éviter l'eval() autant procéder ainsi :

errors = [ZeroDivisionError, AttributeError, IndexError, NameError,
ImportError, KeyboardInterrupt, RecursionError, StopIteration,
SyntaxError, IndentationError, TypeError, UnboundLocalError,
ValueError, KeyError]

Non ?

---

Oui.
Si j'ai utilisé une string c'est seulement pour éviter l'affichage <class ...>:

Code:

---

1 2 3

>>> f"Provoque l'exception {TypeError}" "Provoque l'exception <class 'TypeError'>" >>>

---

Mais bon, je n'en suis pas encore à écrire un code. Je m'intéroge surtout sur sa pertinance. En ce qui concerne wistricks c'est plouf^^
à voir pour les autres. ;)

Bonjour

Citation:

---

Envoyé par Hominidé

Aussi, je me dis qu'il serait probablement intéressant/pédagogique/ludique/utile (?) de proposer un jeu consistant à les provoquer à la demande:
genre: écris un code provoquant l'exception MachinTruc

---

Euh...raise MachinTruc... :aie:

Citation:

---

Envoyé par Sve@r

Bonjour

Euh...raise MachinTruc... :aie:

---

Encore un tricheur ^^

Du coup j'édite le code avec :

Code:

---

1 2 3 4

if f"raise {excep}" in code: print('Tricheur! raise est interdit!') else: print('bravo')

---

;)

Citation:

---

Envoyé par Hominidé

La documentation et les tutoriels( du moins ceux que j'ai parcouru) se contentent de les lister.

---

Certains (dont le mien) les listent dans leur arbre hiérarchique et vont jusqu'à expliquer qu'attrapper une exception dans une branche X attrappe de fait toutes les filles de la branche.

Mais pour le reste, comme le dit Wiztricks, les exceptions on les subit plutôt. Je ne sais pas si les provoquer artificiellement serait utile. Personnellement, quand j'arrive dans une partie de code critique, je commence par écrire le code de façon naturelle puis je teste mon programme en le soumettant à différents stress pour voir les exceptions que ça remonte afin de pouvoir les insérer dans le try/except.
D'autant plus qu'en dehors des exceptions classiques Python, on trouve aussi des exceptions particulières dans les modules qu'on utilise en plus. Par exemple pour Postgres, le module psycopg contient IntegrityError, InternalError et OperationalError et si tu me demandes la différence entre les deux dernières...:?

Je pense que ton idée peut avoir un intérêt pédagogique pour les débutants, je ne connais pas l'efficacité de cette méthode mais on peut imaginer qu'apprendre par l'erreur (@Sve@r nous donnera sûrement un nom plus scientifique) est assez pertinent pour bien comprendre le fonctionnement de base de la programmation et pour avoir les fondamentaux nécessaires au déchiffrage des messages d'erreurs.

Moi je dis pourquoi pas ! :P

@YCL-1 :applo:

Bonjour,
pas évident de rendre les exceptions ludiques, tout comme les pointeurs en C. :mrgreen:

Mais je pense qu'il serait intéressant avant d'essayer de retenir les exceptions les plus utiles, de savoir qu'ils sont hiérarchisés par types d'exception

Pour citer le site offciel : https://docs.python.org/3/library/ex...tion-hierarchy

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

The class hierarchy for built-in exceptions is:   BaseException +-- SystemExit +-- KeyboardInterrupt +-- GeneratorExit +-- Exception +-- StopIteration +-- StopAsyncIteration +-- ArithmeticError | +-- FloatingPointError | +-- OverflowError | +-- ZeroDivisionError +-- AssertionError +-- AttributeError +-- BufferError +-- EOFError +-- ImportError | +-- ModuleNotFoundError +-- LookupError | +-- IndexError | +-- KeyError +-- MemoryError +-- NameError | +-- UnboundLocalError +-- OSError | +-- BlockingIOError | +-- ChildProcessError | +-- ConnectionError | | +-- BrokenPipeError | | +-- ConnectionAbortedError | | +-- ConnectionRefusedError | | +-- ConnectionResetError | +-- FileExistsError | +-- FileNotFoundError | +-- InterruptedError | +-- IsADirectoryError | +-- NotADirectoryError | +-- PermissionError | +-- ProcessLookupError | +-- TimeoutError +-- ReferenceError +-- RuntimeError | +-- NotImplementedError | +-- RecursionError +-- SyntaxError | +-- IndentationError | +-- TabError +-- SystemError +-- TypeError +-- ValueError | +-- UnicodeError | +-- UnicodeDecodeError | +-- UnicodeEncodeError | +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- PendingDeprecationWarning +-- RuntimeWarning +-- SyntaxWarning +-- UserWarning +-- FutureWarning +-- ImportWarning +-- UnicodeWarning +-- BytesWarning +-- EncodingWarning +-- ResourceWarning

---

Ainsi on comprend mieux pourquoi "except Exception" permet d'attraper l'ensemble des exceptions d'exécution en dehors des exceptions "d’échappement" comme KeyboardInterrupt (Ctrl + C) ou encore SystemExit ( exit() ).

Mais pouvoir attraper certaines exceptions plutôt que l'ensemble peut permettre de définir des cas particuliers plutôt de que devoir gérer tout comme une erreur.
Car il faut bien comprendre qu'une exception ne signifie pas forcément une erreur.
Beaucoup de fonctions natives utilisent les exceptions comme un moyen de communiquer plutôt que de tout gérer par un simple return comme le fait le langage C par exemple avec une définition spécifique des erreurs selon le nombre < 0 qu'il retourne.

Lorsqu'on apprend des fonctionnalités avancées comme les itérateurs/générateurs par exemple on apprend que pour signifier la fin de l'itération il suffit de lever l'exception StopIteration.

Aussi c'est important de comprendre les différentes syntaxe try/except/else/finally.
Voici un exemple un peu chargé mais qui permet de présenter les différents cas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

while True: # { try: reponse_str = input("Veuillez entrer un nombre entier : ") valeur = int(reponse_str) except ValueError: # Pas un int, vérifie si c'est un float try: valeur = float(reponse_str) print(f"La valeur {valeur} est un nombre flotant et non un entier !") except ValueError: # Pas un int ni un float -> relance la question print(f"La valeur '{reponse_str}' n'est pas un nombre !") continue # Pas un int -> relance la question # except KeyboardInterrupt: print("Arrêt du test") break # Fin de la boucle else: # Pas d'erreur print(f"La valeur {valeur} est un nombre entier.") break # Fin de la boucle finally: # Dans tous les cas, quand bien même on relance un raise print("_" * 50) # } while

---

Citation:

---

Veuillez entrer un nombre entier : a
La valeur 'a' n'est pas un nombre !
__________________________________________________
Veuillez entrer un nombre entier : 1.5
La valeur 1.5 est un nombre flotant et non un entier !
__________________________________________________
Veuillez entrer un nombre entier : 15
La valeur 15 est un nombre entier.
__________________________________________________

---

Quelques liens utiles :
https://docs.python.org/3/library/exceptions.html
https://docs.python.org/3/tutorial/errors.html

Il y a beaucoup de très bons tuto sur le site sametmarx.com, pas toujours très tout public sur les anciens articles mais ça reste une très bonne référence en Python.

Merci pour l'ensemble de vos remarques.

à la base, ma proposition consiste plutôt à demander à un apprenant à écrire un code de façon à faire râler python de telle ou telle manière . Le but étant de repérer les situations clefs où se manifesteront les exceptions, le tout sous forme de jeu (On pourrait imaginer un système d'indices/correction) En quelque sorte cela permettrait (du moins je l'imagine) de prendre les devants, sur ce qu'inévitablement un apprenant sera confronté (comme vous l'avez si bien dit).
Mais, effectivement un volet sur l'usage des exceptions, avec des exercices de mis en œuvre aurait sa place dans un tel programme...

Je vais laisser décanter tout cela quelques jours, et voir la suite que je vais donner à cette idée.

Citation:

---

Envoyé par Se@v

puis je teste mon programme en le soumettant à différents stress pour voir les exceptions que ça remonte

---

Ne va pas trop les faire stresser non plus... Au risque d'être dénoncé à la protection protectrice des codes maltraités :mouarf: