OVH Cloud OVH Cloud

[future évolution ?] bloc else pour les excpetions

36 réponses
Avatar
Benoit Dejean
est-ce qu'il est prévu d'apporter cette fonctionnalité

try
{
// code pouvant lancer une exception
}
catch()
{
// code exécuté si un exception est lancée
}
else
{
// code exécuté si aucune exception n'a été lancée
}


--
Ne perdez pas de vue qu'un programme qui plante est d'une utilité quasi nulle,
ce qui est loin d'être incompatible avec la notion d'Art.

10 réponses

1 2 3 4
Avatar
Benoit Dejean
Le Wed, 09 Jul 2003 14:06:37 -0400, Michel Michaud a écrit :

Ton « exemple » montre du code qui aurait pu s'écrire plus simplement
sans le else, en mettant le o.print() dans le try.


n'as t on pas intérêt à réduire la taille des blocs try?

Encore une fois, si tu as une raison de faire les choses
ainsi, montre un exemple réaliste...


pas en C++ malheureusement. je n'ai pas besoin de tous ça, je voulais
juste en discuter

--
"Ne perdez pas de vue qu'un programme rapide et incorrect est d'une utilité presque nulle."
Ce qui est loin d'être incompatible avec la notion d'Art.

Avatar
Christophe Lephay
"Benoit Dejean" a écrit dans le message de
news:
Ton « exemple » montre du code qui aurait pu s'écrire plus simplement
sans le else, en mettant le o.print() dans le try.


n'as t on pas intérêt à réduire la taille des blocs try?


on a intérêt de réduire les blocs, qu'ils soient try ou non. Créer des
fonctions est un moyen d'y arriver...


Encore une fois, si tu as une raison de faire les choses


Si tu as une raison de le faire, seule la fréquence d'apparition de cette
nécessité peut justifier de l'incorporer au langage...

ainsi, montre un exemple réaliste...


pas en C++ malheureusement. je n'ai pas besoin de tous ça, je voulais
juste en discuter


Soit en mettant le code dans le bloc try, soit en testant un booléen, tu as
différentes façons de répondre à ce besoin. Si l'écriture n'est pas élégante
ou un peu lourde, ce n'est pas vraiment un problème si celà ne survient que
deux fois par an...

Chris


Avatar
Benoit Dejean
Le Wed, 09 Jul 2003 21:19:21 +0200, Christophe Lephay a écrit :


Soit en mettant le code dans le bloc try, soit en testant un booléen,
tu as différentes façons de répondre à ce besoin. Si l'écriture
n'est pas élégante ou un peu lourde, ce n'est pas vraiment un
problème si celà ne survient que deux fois par an...

Chris


je suis d'accord. je faisais juste une remarque en fait.

--
"Ne perdez pas de vue qu'un programme rapide
et incorrect est d'une utilité presque nulle."
Ce qui est loin d'être incompatible avec la notion d'Art.

Avatar
drkm
Benoit Dejean writes:

try:
result = tk.call('eval', cmd)
except _tkinter.TclError, msg:
print 'TclError:', msg
else:
if result: print result
cmd = ''


Quelle est la différence avec le code suivant ? Je le trouve plus
lisible.

try:
result = tk.call('eval', cmd)
if result:
print result
except _tkinter.TclError, msg:
print 'TclError:', msg
cmd = ''

--drkm

Avatar
Christophe Lephay
"drkm" a écrit dans le message de
news:
Benoit Dejean writes:

try:
result = tk.call('eval', cmd)
except _tkinter.TclError, msg:
print 'TclError:', msg
else:
if result: print result
cmd = ''


Quelle est la différence avec le code suivant ? Je le trouve plus
lisible.

try:
result = tk.call('eval', cmd)
if result:
print result
except _tkinter.TclError, msg:
print 'TclError:', msg
cmd = ''


Voire même :
try:
result = tk.call('eval', cmd)
except _tkinter.TclError, msg:
print 'TclError:', msg
if result:
print result
cmd = ''

Chris


Avatar
Julien Blanc
drkm wrote:
Benoit Dejean writes:


try:
result = tk.call('eval', cmd)
except _tkinter.TclError, msg:
print 'TclError:', msg
else:
if result: print result
cmd = ''



Quelle est la différence avec le code suivant ? Je le trouve plus
lisible.

try:
result = tk.call('eval', cmd)
if result:
print result
except _tkinter.TclError, msg:
print 'TclError:', msg
cmd = ''

--drkm


si print peut lever une _tkinter.TclError (bon, je doute que ça soit le
cas, mais tout de même), les deux codes ne sont pas équivalents.

Après, c'est surtout une question de goût je pense...

--
Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.


Avatar
darkman_spam
"Christophe Lephay" wrote in message
news:<beigf6$eih$...

"drkm" a écrit dans le message de
news:

Quelle est la différence avec le code suivant ? Je le trouve
plus lisible.

try:
result = tk.call('eval', cmd)
if result:
print result
except _tkinter.TclError, msg:
print 'TclError:', msg
cmd = ''


Voire même :
try:
result = tk.call('eval', cmd)
except _tkinter.TclError, msg:
print 'TclError:', msg
if result:
print result
cmd = ''


Si une `_tkinter.TclError´ est levée dans le bloc try, le bloc if
est exécuté dans un cas et pas dans l'autre.

--drkm


Avatar
Christophe Lephay
"drkm" a écrit dans le message de
news:
Si une `_tkinter.TclError´ est levée dans le bloc try, le bloc if
est exécuté dans un cas et pas dans l'autre.


Oui, c'est ce genre de petites différences qui faisait parler Michel de
"presque identique". On peut supprimer le "presque" sans trop d'efforts, du
reste, avec un booléen en rab si c'est vraiment nécessaire...

Chris

Avatar
Benoit Dejean
Le Thu, 10 Jul 2003 15:40:26 +0200, Fabien LE LEZ a écrit :

On Wed, 09 Jul 2003 20:32:07 +0200, Benoit Dejean
wrote:

n'as t on pas intérêt à réduire la taille des blocs try?


Non. En pratique, je mets bien souvent l'ensemble de mon
application dans un bloc try, pour faciliter l'analyse des "unhandled
exceptions"


je me fiche des performances, mais cela n'a pas un trop gros impact? c'est
pas un peu radical comme solution? est ce que vous utilisez souvent les
bloc try au niveau fonctionnel?

--
"Ne perdez pas de vue qu'un programme rapide
et incorrect est d'une utilité presque nulle."
Ce qui est loin d'être incompatible avec la notion d'Art.


Avatar
Jean-Marc Bourguet
Benoit Dejean writes:

je me fiche des performances, mais cela n'a pas un trop gros impact? c'est
pas un peu radical comme solution? est ce que vous utilisez souvent les
bloc try au niveau fonctionnel?


Tres rarement. Un dans main pour demander un bug report, un dans la
boucle d'interaction pour traiter ce qui peut l'etre, a la rigueur un
pour sortir de recursion profonde, pour communiquer entre un callback
et la couche qui l'a installee ou pour traiter des erreurs du genre:
limitation du nombres d'evenements generes.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

1 2 3 4