Discussion :

[MPython Alaplancha]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ...

[wiztricks]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Invité]

Salut !

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[MPython Alaplancha]

Re,

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

mais si on y tient:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Sve@r]

Bonjour

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...

[MPython Alaplancha]

Bonjour

Euh...raise MachinTruc...

Encore un tricheur ^^

Du coup j'édite le code avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Sve@r]

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...

[Invité]

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 !

@YCL-1

[YCL-1]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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.

[MPython Alaplancha]

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.

[MPython Alaplancha]

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