Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Andréï wrote:
Salut,
je fait actuellement un petit prog mais je bloque sur probleme:
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger
ton code, et te maudire quand ils vont tomber là-dessus.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
jean-michel bain-cornu
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus. +1
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger
ton code, et te maudire quand ils vont tomber là-dessus.
+1
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus. +1
Andréï
bruno at modulix wrote:
Andréï wrote:
Salut, je fait actuellement un petit prog mais je bloque sur probleme:
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu une erreur. C'est si mal que ca de prévoir ca? C'est a l'utilisateur de la classe de prévoir la façon dont il veut voir l'erreur traitée.
bruno at modulix wrote:
Andréï wrote:
Salut,
je fait actuellement un petit prog mais je bloque sur probleme:
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger
ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu
une erreur. C'est si mal que ca de prévoir ca? C'est a l'utilisateur de la
classe de prévoir la façon dont il veut voir l'erreur traitée.
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu une erreur. C'est si mal que ca de prévoir ca? C'est a l'utilisateur de la classe de prévoir la façon dont il veut voir l'erreur traitée.
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu une erreur. C'est si mal que ca de prévoir ca?
Oui. La gestion des erreurs se fait avec les exceptions - qui portent beaucoup plus d'information qu'un booléen.
C'est a l'utilisateur de la classe de prévoir la façon dont il veut voir l'erreur traitée.
Justement, tu l'en empêches.
Si tu veux gérer explicitement une erreur, attrape explicitement la (ou les) classes d'exception que tu gères - et gère les effectivement. Celles que tu ne gères pas, laisse les se propager.
Sérieusement, tu devrais suivre ce conseil. Dans ton propre intérêt, d'ailleurs.
Exemple: dans ton code, la troisième instruction dans le bloc try devrait très vraisemblablement[1] lever un TypeError (je parie sur 'str object is not callable', allez savoir pourquoi). Et comme tu attrape cette exception et la passe sous silence, tu vas toi-même passer des heures à te demander pourquoi la connection échoue toujours[3]...
!-p
[1] à moins bien sûr que le paramètre mdp passé au contructeur ne soit un callable, mais bon, dans ce cas il serait peut-être temps de se pencher sur la documentation de ton code[2]
[2] étant bien entendu que la documentation commence par un bon nommage !-)
[3] ... enfin bon, plus maintenant que je t'ai signalé le problème.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger
ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu
une erreur. C'est si mal que ca de prévoir ca?
Oui. La gestion des erreurs se fait avec les exceptions - qui portent
beaucoup plus d'information qu'un booléen.
C'est a l'utilisateur de la
classe de prévoir la façon dont il veut voir l'erreur traitée.
Justement, tu l'en empêches.
Si tu veux gérer explicitement une erreur, attrape explicitement la (ou
les) classes d'exception que tu gères - et gère les effectivement.
Celles que tu ne gères pas, laisse les se propager.
Sérieusement, tu devrais suivre ce conseil. Dans ton propre intérêt,
d'ailleurs.
Exemple: dans ton code, la troisième instruction dans le bloc try
devrait très vraisemblablement[1] lever un TypeError (je parie sur 'str
object is not callable', allez savoir pourquoi). Et comme tu attrape
cette exception et la passe sous silence, tu vas toi-même passer des
heures à te demander pourquoi la connection échoue toujours[3]...
!-p
[1] à moins bien sûr que le paramètre mdp passé au contructeur ne soit
un callable, mais bon, dans ce cas il serait peut-être temps de se
pencher sur la documentation de ton code[2]
[2] étant bien entendu que la documentation commence par un bon nommage !-)
[3] ... enfin bon, plus maintenant que je t'ai signalé le problème.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
La fonction retourne True s'il n'y a pas eu d'erreur et false s'il y a eu une erreur. C'est si mal que ca de prévoir ca?
Oui. La gestion des erreurs se fait avec les exceptions - qui portent beaucoup plus d'information qu'un booléen.
C'est a l'utilisateur de la classe de prévoir la façon dont il veut voir l'erreur traitée.
Justement, tu l'en empêches.
Si tu veux gérer explicitement une erreur, attrape explicitement la (ou les) classes d'exception que tu gères - et gère les effectivement. Celles que tu ne gères pas, laisse les se propager.
Sérieusement, tu devrais suivre ce conseil. Dans ton propre intérêt, d'ailleurs.
Exemple: dans ton code, la troisième instruction dans le bloc try devrait très vraisemblablement[1] lever un TypeError (je parie sur 'str object is not callable', allez savoir pourquoi). Et comme tu attrape cette exception et la passe sous silence, tu vas toi-même passer des heures à te demander pourquoi la connection échoue toujours[3]...
!-p
[1] à moins bien sûr que le paramètre mdp passé au contructeur ne soit un callable, mais bon, dans ce cas il serait peut-être temps de se pencher sur la documentation de ton code[2]
[2] étant bien entendu que la documentation commence par un bon nommage !-)
[3] ... enfin bon, plus maintenant que je t'ai signalé le problème.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Amand Tihon
jean-michel bain-cornu wrote:
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à dé bugger ton code, et te maudire quand ils vont tomber là-dessus. +1
Je me permets de nuancer. C'est presque toujours mal et dans ce cas-ci, ça m'a tout l'air de l'être.
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes handlers mod_python (module python pour le serveur web apache) fait une bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça passe par un 'catch_all', bien évidemment.
Ce type de construction, présent tout en haut de la pile et, j'insist e, *désactivable* (une variable à True dans la version en développem ent) n'est que rarement envisageable à un niveau plus bas.
C'était mes deux centimes vespéro-nocturnes. -- Amand Tihon
jean-michel bain-cornu wrote:
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à dé bugger
ton code, et te maudire quand ils vont tomber là-dessus.
+1
Je me permets de nuancer. C'est presque toujours mal et dans ce cas-ci, ça
m'a tout l'air de l'être.
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes
handlers mod_python (module python pour le serveur web apache) fait une
bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page
d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça
passe par un 'catch_all', bien évidemment.
Ce type de construction, présent tout en haut de la pile et, j'insist e,
*désactivable* (une variable à True dans la version en développem ent) n'est
que rarement envisageable à un niveau plus bas.
C'était mes deux centimes vespéro-nocturnes.
--
Amand Tihon
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à dé bugger ton code, et te maudire quand ils vont tomber là-dessus. +1
Je me permets de nuancer. C'est presque toujours mal et dans ce cas-ci, ça m'a tout l'air de l'être.
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes handlers mod_python (module python pour le serveur web apache) fait une bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça passe par un 'catch_all', bien évidemment.
Ce type de construction, présent tout en haut de la pile et, j'insist e, *désactivable* (une variable à True dans la version en développem ent) n'est que rarement envisageable à un niveau plus bas.
C'était mes deux centimes vespéro-nocturnes. -- Amand Tihon
Bruno Desthuilliers
jean-michel bain-cornu wrote:
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
+1
Je me permets de nuancer.
Et tu a raison. Comme toutes les règles 'absolutiste' (pas de goto, pas de retours anticipés, pas d'attributs publics, etc), elle est relative à la compréhension qu'on a de ce qu'on est en train de faire. Une fois qu'on a compris la raison de la règle, on sait quand (et comment...) ne pas l'appliquer.
C'est presque toujours mal et dans ce cas-ci, ça m'a tout l'air de l'être.
Je confirme !-)
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes handlers mod_python (snip) fait une bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça passe par un 'catch_all', bien évidemment.
Attention quand même, regarde l'implémentation de sys.exit()
Mettre un catch-all au 'sommet' de l'appli est évidemment une bonne pratique, ne serait-ce que pour logger, faire le ménage et s'écraser proprement (mais *pas* silencieusement...) si c'est encore possible. Mais il faut toujours tester ce qu'on attrape et savoir quoi en faire... comme par exemple relancer si c'est un SysExit !-)
Ce type de construction, présent tout en haut de la pile
Oui.
et, j'insiste, *désactivable*
Oui.
n'est que rarement envisageable à un niveau plus bas.
Oui. Il y a des cas - généralement assez "haut" dans une appli ou une bibliothèque - où l'on veut tout attraper, par exemple pour s'assurer de ne laisser passer que certains types d'exception et/ou pour "décorer" l'exception.
C'était mes deux centimes vespéro-nocturnes.
Bienvenus, et éminemment constructifs.
jean-michel bain-cornu wrote:
bruno at modulix wrote:
Andréï wrote:
except:
Argh. Une clause except 'catch_all', et une exception qui passe à la
poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger
ton code, et te maudire quand ils vont tomber là-dessus.
+1
Je me permets de nuancer.
Et tu a raison. Comme toutes les règles 'absolutiste' (pas de goto, pas
de retours anticipés, pas d'attributs publics, etc), elle est relative à
la compréhension qu'on a de ce qu'on est en train de faire. Une fois
qu'on a compris la raison de la règle, on sait quand (et comment...) ne
pas l'appliquer.
C'est presque toujours mal et dans ce cas-ci, ça
m'a tout l'air de l'être.
Je confirme !-)
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes
handlers mod_python (snip) fait une
bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page
d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça
passe par un 'catch_all', bien évidemment.
Attention quand même, regarde l'implémentation de sys.exit()
Mettre un catch-all au 'sommet' de l'appli est évidemment une bonne
pratique, ne serait-ce que pour logger, faire le ménage et s'écraser
proprement (mais *pas* silencieusement...) si c'est encore possible.
Mais il faut toujours tester ce qu'on attrape et savoir quoi en faire...
comme par exemple relancer si c'est un SysExit !-)
Ce type de construction, présent tout en haut de la pile
Oui.
et, j'insiste,
*désactivable*
Oui.
n'est
que rarement envisageable à un niveau plus bas.
Oui. Il y a des cas - généralement assez "haut" dans une appli ou une
bibliothèque - où l'on veut tout attraper, par exemple pour s'assurer de
ne laisser passer que certains types d'exception et/ou pour "décorer"
l'exception.
Argh. Une clause except 'catch_all', et une exception qui passe à la poubelle. *c'est mal*. Il y en a qui vont passer des heures à débugger ton code, et te maudire quand ils vont tomber là-dessus.
+1
Je me permets de nuancer.
Et tu a raison. Comme toutes les règles 'absolutiste' (pas de goto, pas de retours anticipés, pas d'attributs publics, etc), elle est relative à la compréhension qu'on a de ce qu'on est en train de faire. Une fois qu'on a compris la raison de la règle, on sait quand (et comment...) ne pas l'appliquer.
C'est presque toujours mal et dans ce cas-ci, ça m'a tout l'air de l'être.
Je confirme !-)
Mais il arrive parfois qu'on veuille vraiment tout catcher. Quand un de mes handlers mod_python (snip) fait une bêtise, quelle qu'elle soit, l'utilisateur ne doit voir qu'une page d'erreur générique, et je reçois la pile d'appels dans les logs. Et ça passe par un 'catch_all', bien évidemment.
Attention quand même, regarde l'implémentation de sys.exit()
Mettre un catch-all au 'sommet' de l'appli est évidemment une bonne pratique, ne serait-ce que pour logger, faire le ménage et s'écraser proprement (mais *pas* silencieusement...) si c'est encore possible. Mais il faut toujours tester ce qu'on attrape et savoir quoi en faire... comme par exemple relancer si c'est un SysExit !-)
Ce type de construction, présent tout en haut de la pile
Oui.
et, j'insiste, *désactivable*
Oui.
n'est que rarement envisageable à un niveau plus bas.
Oui. Il y a des cas - généralement assez "haut" dans une appli ou une bibliothèque - où l'on veut tout attraper, par exemple pour s'assurer de ne laisser passer que certains types d'exception et/ou pour "décorer" l'exception.
