Trop la classe, j’ai mon poste sur le site et j’ai trouvé une coquille de maitre SAM ! :)

Comment je suis fier !

Je vais bien souler mes collègues avec ça et m’inspirer de cet article de référence http://sametmax.com/le-bon-coup-de-pute-du-jeudi/#tc-comment-title pour communiquer ma joie.

Plus sérieusement, j’en profite pour vous remercier, super site avec plein de contenu intéressant et avec un un ton pas prise de tête.

J’ai appris plein de trucs grâce à ce site.

Je crois qu’il y a une petite coquille :

On peut gérer plusieurs exceptions avec un seul bloc :

    try:
        return personnages[100 / i]
        # est exécuté pour ces deux exceptions
    except IndexError, ZeroDivisionError:
        return None

La ligne :

 
except IndexError, ZeroDivisionError:

devrait être :

 
except (IndexError, ZeroDivisionError):

D’après la doc ici https://docs.python.org/2/tutorial/errors.html#handling-exceptions :

A try statement may have more than one except clause, to specify handlers for different exceptions. At most one handler will be executed. Handlers only handle exceptions that occur in the corresponding try clause, not in other handlers of the same try statement. An except clause may name multiple exceptions as a parenthesized tuple, for example:

... except (RuntimeError, TypeError, NameError):
...     pass

Ou j’ai loupé un truc ?

Au niveau des exceptions personnalisées, comment faire ça clairement ? Faut-il créer une exception par message ? Par classe ? Par type (MyValueError, MyIOError…) ?

Sinon, y’a un joli moyen de tuer le concept d’exceptions en Python (pour le fuuuun) : FuckIt.py (https://github.com/ajalt/fuckitpy)

Il me semble qu’il parse l’AST pour silencer tous les exceptions (deal with 0/0 now). Enfin, c’est drôle.

Quelques typos:

un motif récurant -> un motif récurrent

Quand vous attraper -> Quand vous attrapez

le bloc […] est appelée -> le bloc […] est appelé

gérer toujours l’erreur -> gérez toujours l’erreur (pas sûr pour celle-là, ça dépend de ce que tu veux dire)

quand vous créé -> quand vous créez

on a pas la garantie -> on n’a pas la garantie

ce que vous branler -> ce que vous branlez

Je plaide coupable pour : 1. Attraper systématiquement Exception (et logger.exception(e)) ; 2. Préférer checker mes données avec des if plutôt que d’ “abuser” des exceptions, je trouve pas ça naturel.

Je vais essayer de me redresser productivement.

Je connaissais pas sys.excepthook, je vais essayer d’utiliser ça pour mes sorties webs. Jusqu’à présent j’utilisais timidement cgi.enable.

Pour IOError par contre, c’est plus compliqué : en 2.7, oui tu dois checker e.errno. En Python 3, le problème a été résolu en ajouter de nouvelles exceptions : https://docs.python.org/3/library/exceptions.html#os-exceptions

De mon côté il y a un truc que je ne sais pas faire correctement je pense. Il peut arriver qu’un ValueError par exemple soit levé avec un message A ou avec un message B. Et dans certains cas je veux que le message A soit attrapé et non bloquant et le message B je veux qu’il ne le soit pas. Donc ce que je fais en général c’est un :

Sauf que j’ai vu, je ne sais plus où qu’il ne faut pas utiliser le e.message. Du coup il faut utiliser le e.errno ? Ou il y a un autre moyen plus conseillé ?