Bonjour,
Je viens de creer ma propre exception, qui se lance si un algorithme particulier a planté. Pour éviter de montrer beaucoup de lignes de code, j'ai simplifié en écrivant ceci :

try:
    try:
        # mon algorithme qui plante a un endroit inconnu, que j'aimerai connaitre
        a = 2/0
    except:
        raise "myExc", "le texte de mon exception"
except "myExc", text:
    print text

Les lignes 2 a 6 sont dans un module independant de l'interface graphique.
Les autres lignes sont dans mon interface graphique. Elle me permettent de lancer une boite de dialogue ou j'afficherai "myExc" et le contenu de la variable text. Le probleme, c'est qu'avec ce systeme, je n'ai aucune information sur la raison principale de plantage. Ici il s'agit d'un ZeroDivisionError. Quelqu'un sait comment je pourrai récupérer cette exception, qui pourrai être autre chose qu'une ZeroDivisionError ?

Merci d'avance

D'après la doc ( http://docs.python.org/reference/compo [...] s.html#except ), tu peux utiliser sys.exc_type (par exemple l'afficher), sys.exc_value (les paramètres de l'exception) ou sys.exc_traceback, ou encore sys.exc_info qui renvoie un tuple contenant ces trois valeurs.

La prochaine fois, pense à préciser en titre de topic que le langage est Python.

J'ai rajouter [python] devant le nom de mon post, c'était un oubli.

Sinon mon code est devenu :

from sys import exc_info
try:
    try:
        # mon algorithme qui plante a un endroit inconnu, que j'aimerai connaitre
        a = 2/0
    except:
        raise "myExc", ("le texte de mon exception", exc_info()[1])
except "myExc", value:
    print value[0] # affiche le texte de mon exception
    print value[1].__class__.__name__ # affiche le nom de la première exception
    print str(value[1]) # affiche le message de la première exception

Maintenant ça marche, j'arrive à récupérer les informations de la 1ère exception qui a été lancé, et qui a été la conséquence de mon exception. Par contre j'ai un DepreciationWarning, donc j'ai probablement fait un truc de manière pas très élégante.

Merci de m'avoir répondu

Salut !

Citation : cedrix

Par contre j'ai un DepreciationWarning, donc j'ai probablement fait un truc de manière pas très élégante.

Pas nécessairement. Cet avertissement indique surtout que tu utilises une fonctionnalité obsolète pour laquelle il existe désormais une alternative. De là à dire que ce n'est pas élégant... Python évolue vite et beaucoup.

Cordialement,
Cacophrène

Ça y est, tous les Camliens se mettent à Python... Mais où va le monde...

Salut !

Timeo hominem unius libri, je me méfie de l'homme d'un seul livre, écrivait Saint Thomas d'Aquin en des temps lointains. Gageons que c'est encore vrai sous une forme plus moderne : méfions-nous des fanatiques d'un seul langage

Cordialement,
Cacophrène

PS : et puis non, l'exotisme n'est pas une trahison.

Un exception se créé en créant une classe dérivée de la classe Exception.

class MonException(Exception):
    def __init__(self):
        print "Erreur: ça ne marche pas."

Si tu veux lever une exception, par exemple ZeroDivisionError>:

try:
    a = 2 / 0
except ZeroDivisionError: # Si il y a une ZeroDivisionError
    print "Erreur: division par zéro." # On affiche ceci

Ce code permet d'éviter l'interruption du programme en cas de ZeroDivisionError. Ca
affichera à la place "Erreur: division par zéro."

D'ailleurs, quand je tape raise "MyExc" dans le shell:

>>>raise "MyExc"
Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
TypeError: exceptions must be classes or instance, not str
>>>

Bien expliqué à un détail de vocabulaire près : lever une exception, c'est avec raise.
except, c'est pour la rattraper.
(en gros)

Oui, tu as raison !
En gros, avec try...except...else/finally, on gère les exceptions, on gère le cas où une exceptions se produirait, pour éviter l'interruption du programme
Bien sure il ne faut pas abuser de cela: il se peut que l'on rattrape une exception, et qu'après tout le programme soit faussé et enchaîne ensuite une foulée d'exceptions

lucky-84 : d'une part, le récapitulatif m'a l'air un peu superflu, parce que cedrix savait visiblement utiliser les exceptions (en tout cas le problème ne portait pas directement là dessus, et rien ne laisse soupçonner un manque de ce côté). Après, si tu aimes reformuler des explications à ta manière, ça ne dérange sans doute personne mais amha tu perds ton temps.

Citation

Bien sure il ne faut pas abuser de cela: il se peut que l'on rattrape une exception, et qu'après tout le programme soit faussé et enchaîne ensuite une foulée d'exceptions

Rattraper une exception n'est intéressant que quand on peut remettre ensuite le programme dans un état lui permettant de continuer son exécution sans souçis. Si ça va planter, il faut s'arrêter en détaillant l'erreur. Le cas de figure que tu cites découle à mon avis d'une mauvaise utilisation de try

Citation : bluestorm

Après, si tu aimes reformuler des explications à ta manière, ça ne dérange sans doute personne mais amha tu perds ton temps.

C'est pas tout à fait faux

Citation : bluestorm

d'une part, le récapitulatif m'a l'air un peu superflu, parce que cedrix savait visiblement utiliser les exceptions (en tout cas le problème ne portait pas directement là dessus, et rien ne laisse soupçonner un manque de ce côté).

En fait ce qui me gênait un peu, c'est que cedrix disait "Je viens de creer ma propre exception", alors que l'on ne voyait nulle part de classe dérivant de la classe Exception
Mais c'est quand même un peu vrai