[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.
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?
La taille de blocs try n'aura aucune importance. C'est la mise en place d'un bloc try (donc ce qu'il faut pour traiter les exceptions) qui ajoute un peu de code, et encore...
Je n'utilise des blocs try que lorsqu'il en faut. N'est-ce pas la seule possibilité ?
-- 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.10.15.33.39.141979@ifrance.com, Benoit
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?
La taille de blocs try n'aura aucune importance. C'est la mise
en place d'un bloc try (donc ce qu'il faut pour traiter les
exceptions) qui ajoute un peu de code, et encore...
Je n'utilise des blocs try que lorsqu'il en faut. N'est-ce pas
la seule possibilité ?
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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?
La taille de blocs try n'aura aucune importance. C'est la mise en place d'un bloc try (donc ce qu'il faut pour traiter les exceptions) qui ajoute un peu de code, et encore...
Je n'utilise des blocs try que lorsqu'il en faut. N'est-ce pas la seule possibilité ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Christophe Lephay
"Benoit Dejean" a écrit dans le message de news:
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?
Celà n'a aucun impact sur les performances tant qu'aucune exception survient. Et si une exception survient, c'est pour un cas d'erreur qu'il aurait de toute façon fallu traiter (qu'on ne peut donc pas comparer avec le code normal).
Chris
"Benoit Dejean" <bnet@ifrance.com> a écrit dans le message de
news:pan.2003.07.10.15.33.39.141979@ifrance.com...
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?
Celà n'a aucun impact sur les performances tant qu'aucune exception
survient. Et si une exception survient, c'est pour un cas d'erreur qu'il
aurait de toute façon fallu traiter (qu'on ne peut donc pas comparer avec le
code normal).
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?
Celà n'a aucun impact sur les performances tant qu'aucune exception survient. Et si une exception survient, c'est pour un cas d'erreur qu'il aurait de toute façon fallu traiter (qu'on ne peut donc pas comparer avec le code normal).
Chris
Christophe Lephay
"Fabien LE LEZ" a écrit dans le message de news:
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 n'inteprete pas comme celà l'expression "réduire la taille d'un bloc try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est pas la nouvelle insulte à la mode ;)
Chris
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:r2rqgvs6v64u68lqt1ad7p2da10kc7a71m@4ax.com...
Je n'inteprete pas comme celà l'expression "réduire la taille d'un bloc
try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est
pas la nouvelle insulte à la mode ;)
Je n'inteprete pas comme celà l'expression "réduire la taille d'un bloc try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est pas la nouvelle insulte à la mode ;)
Chris
Fabien LE LEZ
On Thu, 10 Jul 2003 20:00:01 +0200, "Christophe Lephay" wrote:
Je n'inteprete pas comme celà l'expression "réduire la taille d'un bloc try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est pas la nouvelle insulte à la mode ;)
Sauf qu'en terme de performances, le code
void g() { (CODE_1) }
void f() { try { g(); } ... }
est plus lent que
void f() { try { (CODE_1) } ... }
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction en plus...
-- 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
Je n'inteprete pas comme celà l'expression "réduire la taille d'un bloc
try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est
pas la nouvelle insulte à la mode ;)
Sauf qu'en terme de performances, le code
void g()
{
(CODE_1)
}
void f()
{
try
{
g();
}
...
}
est plus lent que
void f()
{
try
{
(CODE_1)
}
...
}
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction
en plus...
--
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 Thu, 10 Jul 2003 20:00:01 +0200, "Christophe Lephay" wrote:
Je n'inteprete pas comme celà l'expression "réduire la taille d'un bloc try". En d'autres termes, je trouve que ton bloc est réduit - non, ce n'est pas la nouvelle insulte à la mode ;)
Sauf qu'en terme de performances, le code
void g() { (CODE_1) }
void f() { try { g(); } ... }
est plus lent que
void f() { try { (CODE_1) } ... }
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction en plus...
-- 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
Christophe Lephay
"Fabien LE LEZ" a écrit dans le message de news:
Sauf qu'en terme de performances, le code ...
est plus lent que ...
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction en plus...
lol
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
Chris
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:86orgvkjiia60v40hi4iam5hubqc4qsh35@4ax.com...
Sauf qu'en terme de performances, le code
...
est plus lent que
...
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction
en plus...
lol
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
même si (CODE_1) fait 100 lignes, puisqu'il y a un appel de fonction en plus...
lol
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
Chris
Fabien LE LEZ
On Fri, 11 Jul 2003 02:14:19 +0200, "Christophe Lephay" wrote:
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
Ce que je voulais dire, c'est que le fait qu'il n'y ait qu'une seule ligne dans le bloc try n'indique pas que ce bloc est "court" (en terme de temps d'exécution ou de taille de code exécuté).
-- 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
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
Ce que je voulais dire, c'est que le fait qu'il n'y ait qu'une seule
ligne dans le bloc try n'indique pas que ce bloc est "court" (en terme
de temps d'exécution ou de taille de code exécuté).
--
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 Fri, 11 Jul 2003 02:14:19 +0200, "Christophe Lephay" wrote:
y a qu'à mettre la fonction inline, si c'est vraiment un problème ;)
Ce que je voulais dire, c'est que le fait qu'il n'y ait qu'une seule ligne dans le bloc try n'indique pas que ce bloc est "court" (en terme de temps d'exécution ou de taille de code exécuté).
-- 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
