[future évolution ?] bloc else pour les excpetions
36 réponses
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.
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit :
On Tue, 08 Jul 2003 05:33:33 +0200, Benoit Dejean wrote:
mais moi j'attends du bloc else, c'est qu'il soit exécuté si aucune exception n'est lancée: si une exception attendue est survenue ou si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
Relis ta phrase, et tu t'apercevras que non ;-)
Bon, prenons un exemple :
class A {}; class B {};
enum { NO_THROW, THROW_A, THROW_B };
void f (int action) { try { switch (action) { case 1: throw A(); case 2: throw B(); } } catch (A) { } else { ... } }
Dans lesquels des cas suivants le "bloc else" doit-il être exécuté suivant tes spécifications ? f(NO_THROW); f(THROW_A); f(THROW_B);
NO_THROW
-- "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.
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit :
mais moi j'attends du bloc else, c'est qu'il soit exécuté si
aucune exception n'est lancée: si une exception attendue est survenue ou
si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
Relis ta phrase, et tu t'apercevras que non ;-)
Bon, prenons un exemple :
class A {};
class B {};
enum { NO_THROW, THROW_A, THROW_B };
void f (int action)
{
try
{
switch (action)
{
case 1: throw A();
case 2: throw B();
}
}
catch (A)
{
}
else
{
...
}
}
Dans lesquels des cas suivants le "bloc else" doit-il être exécuté
suivant tes spécifications ?
f(NO_THROW);
f(THROW_A);
f(THROW_B);
NO_THROW
--
"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.
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit :
On Tue, 08 Jul 2003 05:33:33 +0200, Benoit Dejean wrote:
mais moi j'attends du bloc else, c'est qu'il soit exécuté si aucune exception n'est lancée: si une exception attendue est survenue ou si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
Relis ta phrase, et tu t'apercevras que non ;-)
Bon, prenons un exemple :
class A {}; class B {};
enum { NO_THROW, THROW_A, THROW_B };
void f (int action) { try { switch (action) { case 1: throw A(); case 2: throw B(); } } catch (A) { } else { ... } }
Dans lesquels des cas suivants le "bloc else" doit-il être exécuté suivant tes spécifications ? f(NO_THROW); f(THROW_A); f(THROW_B);
NO_THROW
-- "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.
Julien Blanc
Benoit Dejean wrote:
On Mon, 07 Jul 2003 21:12:13 +0200, Benoit Dejean wrote:
Objet o;
try { o= fonction(); } catch(exception &e) { // traitement d'erreur // mais qui n'implique pas d'instruction d'arrêt } else
Essaie en remplaçant le "else" par catch (...) { throw; }
ça ne remplace pas du tout. Dans le cas ou l'exception déclenchée est inattendue, elle remonte, else ou pas else. d'ailleurs il me semble que ce bloc est le comportement par défaut non? mais je vois ou tu veux en venir. mais moi j'attends du bloc else, c'est qu'il soit exécuté si aucune exception n'est lancée: si une exception attendue est survenue ou si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait la plus simple :
try { /actions/ /actions si pas d'exception/ } catch() { /récupération/ }
ne te convient pas ?
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
-- Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
try
{
o= fonction();
}
catch(exception &e)
{
// traitement d'erreur
// mais qui n'implique pas d'instruction d'arrêt
}
else
Essaie en remplaçant le "else" par
catch (...) { throw; }
ça ne remplace pas du tout. Dans le cas ou l'exception déclenchée est
inattendue, elle remonte, else ou pas else. d'ailleurs il me semble que ce
bloc est le comportement par défaut non? mais je vois ou tu veux en
venir. mais moi j'attends du bloc else, c'est qu'il soit exécuté si
aucune exception n'est lancée: si une exception attendue est survenue ou
si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait
la plus simple :
try {
/actions/
/actions si pas d'exception/
}
catch() { /récupération/ }
ne te convient pas ?
est-ce parce que ton bloc d'actions si pas d'exception est susceptible
d'en lever une qui pourrait être interceptée par les catch qui suivent ?
Ca me parait douteux conceptuellement.
--
Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
On Mon, 07 Jul 2003 21:12:13 +0200, Benoit Dejean wrote:
Objet o;
try { o= fonction(); } catch(exception &e) { // traitement d'erreur // mais qui n'implique pas d'instruction d'arrêt } else
Essaie en remplaçant le "else" par catch (...) { throw; }
ça ne remplace pas du tout. Dans le cas ou l'exception déclenchée est inattendue, elle remonte, else ou pas else. d'ailleurs il me semble que ce bloc est le comportement par défaut non? mais je vois ou tu veux en venir. mais moi j'attends du bloc else, c'est qu'il soit exécuté si aucune exception n'est lancée: si une exception attendue est survenue ou si une exception inattendue est survenue (et remontée donc, normal)
je suis pas clair?
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait la plus simple :
try { /actions/ /actions si pas d'exception/ } catch() { /récupération/ }
ne te convient pas ?
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
-- Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
Benoit Dejean
Le Tue, 08 Jul 2003 14:01:27 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait la plus simple :
try { /actions/ /actions si pas d'exception/ } catch() { /récupération/ }
ne te convient pas ?
non, voir mes messages précédents.
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien de douteux. on est pessimiste, on essaye de capturer des exceptions, pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
-- "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.
Le Tue, 08 Jul 2003 14:01:27 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait
la plus simple :
try {
/actions/
/actions si pas d'exception/
}
catch() { /récupération/ }
ne te convient pas ?
non, voir mes messages précédents.
est-ce parce que ton bloc d'actions si pas d'exception est susceptible
d'en lever une qui pourrait être interceptée par les catch qui suivent
? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc
else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que
else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien
de douteux. on est pessimiste, on essaye de capturer des exceptions,
pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
--
"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.
Le Tue, 08 Jul 2003 14:01:27 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
en fait, ce qui n'est pas clair, c'est pourquoi la solution qui parait la plus simple :
try { /actions/ /actions si pas d'exception/ } catch() { /récupération/ }
ne te convient pas ?
non, voir mes messages précédents.
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien de douteux. on est pessimiste, on essaye de capturer des exceptions, pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
-- "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.
Julien Blanc
Benoit Dejean wrote:
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien de douteux. on est pessimiste, on essaye de capturer des exceptions, pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
mais le cas où aucune exception n'est levée, c'est le cas où ton programme s'exécute convenablement, donc je ne vois pas vraiment l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme. Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit propager l'information.
me parait plus que douteux puisque soit on récupère de manière correcte dans le catch, et dans ce cas il faut bien finir le traitement, soit on ne le fait pas et dans ce cas on ne propage pas l'information, ce qui équivaut à se moquer éperduement de l'erreur. J'ai vraiment du mal à cerner un cas où ça pourrait être utile (si tu as un exemple concret assez court...)
Ceci dit, la solution pour arriver à un résultat similaire t'as été donnée, il faut utiliser soit un branchement return, soit un booléen.
-- Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
Benoit Dejean wrote:
est-ce parce que ton bloc d'actions si pas d'exception est susceptible
d'en lever une qui pourrait être interceptée par les catch qui suivent
? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc
else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que
else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien
de douteux. on est pessimiste, on essaye de capturer des exceptions,
pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
mais le cas où aucune exception n'est levée, c'est le cas où ton
programme s'exécute convenablement, donc je ne vois pas vraiment
l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur
n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme.
Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit
propager l'information.
me parait plus que douteux puisque soit on récupère de manière correcte
dans le catch, et dans ce cas il faut bien finir le traitement, soit on
ne le fait pas et dans ce cas on ne propage pas l'information, ce qui
équivaut à se moquer éperduement de l'erreur. J'ai vraiment du mal à
cerner un cas où ça pourrait être utile (si tu as un exemple concret
assez court...)
Ceci dit, la solution pour arriver à un résultat similaire t'as été
donnée, il faut utiliser soit un branchement return, soit un booléen.
--
Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
est-ce parce que ton bloc d'actions si pas d'exception est susceptible d'en lever une qui pourrait être interceptée par les catch qui suivent ? Ca me parait douteux conceptuellement.
je n'ai jamais dit le contraire mais la n'est pas le problème. le bloc else peut lui même contenir des blocs try/catch, etc. je n'ai pas dit que else devait être un bloc qui ne lève pas d'exception. ça n'a donc rien de douteux. on est pessimiste, on essaye de capturer des exceptions, pourquoi ne pas aussi envisager le cas où aucune exception n'est levée?
mais le cas où aucune exception n'est levée, c'est le cas où ton programme s'exécute convenablement, donc je ne vois pas vraiment l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme. Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit propager l'information.
me parait plus que douteux puisque soit on récupère de manière correcte dans le catch, et dans ce cas il faut bien finir le traitement, soit on ne le fait pas et dans ce cas on ne propage pas l'information, ce qui équivaut à se moquer éperduement de l'erreur. J'ai vraiment du mal à cerner un cas où ça pourrait être utile (si tu as un exemple concret assez court...)
Ceci dit, la solution pour arriver à un résultat similaire t'as été donnée, il faut utiliser soit un branchement return, soit un booléen.
-- Julien Blanc. Equipe cadp. VERIMAG. Grenoble. France.
Benoit Dejean
Le Tue, 08 Jul 2003 14:43:21 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
mais le cas où aucune exception n'est levée, c'est le cas où ton programme s'exécute convenablement, donc je ne vois pas vraiment l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme. Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit propager l'information.
me parait plus que douteux puisque soit on récupère de manière correcte dans le catch, et dans ce cas il faut bien finir le traitement, soit on ne le fait pas et dans ce cas on ne propage pas l'information, ce qui équivaut à se moquer éperduement de l'erreur. J'ai vraiment du mal à cerner un cas où ça pourrait être utile (si tu as un exemple concret assez court...)
j'ai déjà posté un petit morceau, mais c'est assez maladroit en C++
pourtant ça me parait utile de savoir si une erreur s'est produite ou pas
Ceci dit, la solution pour arriver à un résultat similaire t'as été donnée, il faut utiliser soit un branchement return, soit un booléen.
je continue avec ma floppée de booléens. je vous faisais juste part du fait que certains langages portent un interet au bloc else.
-- "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.
Le Tue, 08 Jul 2003 14:43:21 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
mais le cas où aucune exception n'est levée, c'est le cas où ton
programme s'exécute convenablement, donc je ne vois pas vraiment
l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur
n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme.
Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit
propager l'information.
me parait plus que douteux puisque soit on récupère de manière
correcte dans le catch, et dans ce cas il faut bien finir le traitement,
soit on ne le fait pas et dans ce cas on ne propage pas l'information,
ce qui équivaut à se moquer éperduement de l'erreur. J'ai vraiment du
mal à cerner un cas où ça pourrait être utile (si tu as un exemple
concret assez court...)
j'ai déjà posté un petit morceau, mais c'est assez maladroit en C++
pourtant ça me parait utile de savoir si une erreur s'est produite ou pas
Ceci dit, la solution pour arriver à un résultat similaire t'as été
donnée, il faut utiliser soit un branchement return, soit un booléen.
je continue avec ma floppée de booléens. je vous faisais juste part du
fait que certains langages portent un interet au bloc else.
--
"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.
Le Tue, 08 Jul 2003 14:43:21 +0200, Julien Blanc a écrit :
Benoit Dejean wrote:
mais le cas où aucune exception n'est levée, c'est le cas où ton programme s'exécute convenablement, donc je ne vois pas vraiment l'intérêt conceptuel d'un traitement spécifique au cas "aucune erreur n'est intervenue".
s'il n'y a pas d'erreurs, on continue l'exécution normale du programme. Et s'il y'a erreur, et bien, il faut soit récupérer cette erreur soit propager l'information.
me parait plus que douteux puisque soit on récupère de manière correcte dans le catch, et dans ce cas il faut bien finir le traitement, soit on ne le fait pas et dans ce cas on ne propage pas l'information, ce qui équivaut à se moquer éperduement de l'erreur. J'ai vraiment du mal à cerner un cas où ça pourrait être utile (si tu as un exemple concret assez court...)
j'ai déjà posté un petit morceau, mais c'est assez maladroit en C++
pourtant ça me parait utile de savoir si une erreur s'est produite ou pas
Ceci dit, la solution pour arriver à un résultat similaire t'as été donnée, il faut utiliser soit un branchement return, soit un booléen.
je continue avec ma floppée de booléens. je vous faisais juste part du fait que certains langages portent un interet au bloc else.
-- "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.
Fabien LE LEZ
On Tue, 08 Jul 2003 12:10:37 +0200, Benoit Dejean wrote:
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit : [snip 50 lignes] NO_THROW
Oh le goret-quote :-(
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit :
[snip 50 lignes]
NO_THROW
Oh le goret-quote :-(
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On Tue, 08 Jul 2003 12:10:37 +0200, Benoit Dejean wrote:
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit : [snip 50 lignes] NO_THROW
Oh le goret-quote :-(
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Fabien LE LEZ
On Tue, 08 Jul 2003 21:23:03 +0200, Benoit Dejean wrote:
j'ai certes était totemisé chez les Scout comme 'Sanglier' mais je crois que c'est pas de ça que tu parles...
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes d'un message pour rajouter 3 mots...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
j'ai certes était totemisé chez les Scout comme 'Sanglier' mais je crois
que c'est pas de ça que tu parles...
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes
d'un message pour rajouter 3 mots...
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
On Tue, 08 Jul 2003 21:23:03 +0200, Benoit Dejean wrote:
j'ai certes était totemisé chez les Scout comme 'Sanglier' mais je crois que c'est pas de ça que tu parles...
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes d'un message pour rajouter 3 mots...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Benoit Dejean
Le Tue, 08 Jul 2003 22:59:20 +0200, Fabien LE LEZ a écrit :
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes d'un message pour rajouter 3 mots...
j'ai pas fait gaffe...
-- "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.
Le Tue, 08 Jul 2003 22:59:20 +0200, Fabien LE LEZ a écrit :
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes d'un
message pour rajouter 3 mots...
j'ai pas fait gaffe...
--
"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.
Le Tue, 08 Jul 2003 22:59:20 +0200, Fabien LE LEZ a écrit :
Non, effectivement. Je parlais du AOL-quote : on cite les 50 lignes d'un message pour rajouter 3 mots...
j'ai pas fait gaffe...
-- "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.
drkm
Fabien LE LEZ writes:
On Tue, 08 Jul 2003 12:10:37 +0200, Benoit Dejean wrote:
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit : [snip 50 lignes] NO_THROW
On Tue, 08 Jul 2003 12:10:37 +0200, Benoit Dejean wrote:
Le Tue, 08 Jul 2003 07:46:49 +0200, Fabien LE LEZ a écrit : [snip 50 lignes] NO_THROW
Oh le goret-quote :-(
Tu veux dire une quote de porc ?
--drkm
Michel Michaud
Dans news:, Benoit
je n'ai pas vraiment de code sous la main, puisque j'évite cette manière de faire en C++, mais programmant également beaucoup en python, j'utilise énormément ceci dans mes scripts.
voilà un petit exemple
Objet o;
try { o= fonction(); } catch(exception &e) { // traitement d'erreur // mais qui n'implique pas d'instruction d'arrêt } else { // AUCUNE exception n'a été déclenchée // (et non pas aucune exception capturée) // opérations avec o // délibérément hors contrôle du try précédent o.print(); // par exemple }
mon idée n'est évidemment pas de tout mélanger, juste d'évoquer cette fonctionnalité. Je n'ai pas l'ambition de dire ce qui est bien ou pas, mais comme j'utilise souvent cette technique par ailleurs, je vous en fait par.
Ton « exemple » montre du code qui aurait pu s'écrire plus simplement sans le else, en mettant le o.print() dans le try. Encore une fois, si tu as une raison de faire les choses ainsi, montre un exemple réaliste...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:pan.2003.07.07.19.12.12.851752@ifrance.com, Benoit
je n'ai pas vraiment de code sous la main, puisque j'évite cette
manière de faire en C++, mais programmant également beaucoup en
python, j'utilise énormément ceci dans mes scripts.
voilà un petit exemple
Objet o;
try
{
o= fonction();
}
catch(exception &e)
{
// traitement d'erreur
// mais qui n'implique pas d'instruction d'arrêt
}
else
{
// AUCUNE exception n'a été déclenchée
// (et non pas aucune exception capturée)
// opérations avec o
// délibérément hors contrôle du try précédent
o.print(); // par exemple
}
mon idée n'est évidemment pas de tout mélanger, juste d'évoquer
cette fonctionnalité. Je n'ai pas l'ambition de dire ce qui est
bien ou pas, mais comme j'utilise souvent cette technique par
ailleurs, je vous en fait par.
Ton « exemple » montre du code qui aurait pu s'écrire plus
simplement sans le else, en mettant le o.print() dans le
try. Encore une fois, si tu as une raison de faire les choses
ainsi, montre un exemple réaliste...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
je n'ai pas vraiment de code sous la main, puisque j'évite cette manière de faire en C++, mais programmant également beaucoup en python, j'utilise énormément ceci dans mes scripts.
voilà un petit exemple
Objet o;
try { o= fonction(); } catch(exception &e) { // traitement d'erreur // mais qui n'implique pas d'instruction d'arrêt } else { // AUCUNE exception n'a été déclenchée // (et non pas aucune exception capturée) // opérations avec o // délibérément hors contrôle du try précédent o.print(); // par exemple }
mon idée n'est évidemment pas de tout mélanger, juste d'évoquer cette fonctionnalité. Je n'ai pas l'ambition de dire ce qui est bien ou pas, mais comme j'utilise souvent cette technique par ailleurs, je vous en fait par.
Ton « exemple » montre du code qui aurait pu s'écrire plus simplement sans le else, en mettant le o.print() dans le try. Encore une fois, si tu as une raison de faire les choses ainsi, montre un exemple réaliste...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
