Combien de langage va-t-on inventer encore en informatique ?
Le c/c++; java; basic; Pascal; ....etc... etc...
Pourquoi perdre son temps avec ces idiomes...hein...
Pourquoi ne pas s'en tenir comme nous le faisons nous tous à l'esperanto ?
Une seule langue et puis c'est tout.
Voilà..j'attends vos commentaires.
On avait donc tort d'être "structurellement sûr" (il n'y a que vous pour être structurement sûr :-)) qu'elles ne peuvent pas se produire, puisque de fait, elles se produisent, non ?
Évidemment.
C'est effectivemetn pire que le départ *si* on "ignore silencieusement" des exceptions (j'imagine que ça veut dire mettre un catch vide par exemple), mais ne suffit-il pas de ne *jamais* le faire et de toujours avoir une politique pour traiter les exceptions déclarées comme pouvant se produire, même si on est "sûr" qu'elles ne peuvent pas se produire ?
C'est contraire au principe d'une exception : le principe des exceptions, c'est qu'il ne faut la traiter que quand elle est pertinente, et que dans tous les autres cas, elle court-circuite le flot normal du code, de sorte que son traitement s'hérite suivant la structure dynamique du programme.
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ? Il consiste finalement à dire que ce n'est pas l'utilisateur de la classe qui decide si l'exception est "pertinente", mais son concepteur : d'une certaine façon, si je comprends bien la logique, la politique de traitement des exceptions (le fait de la décider pertinente ou pas) est définis dans l'API, pas dans son utilisation. En quoi ce n'est pas défendable ?
J'avoue qu'il m'arrive de changer une exception "checkée" en exception "non checkée", particulièrement en ayant recours au sympathique IllegalArgumentException ou IllegalStateException, de façon à faire remonter sans emmerdements une exception d'une couche basse à une couche haute à travers une couche intermédiaire, de la récupérer dans la couche haute et de la retransformer en exception "checkée". Je sais pas si c'est défendable.
Ainsi, la politique que tu évoques peut -- et doit -- être mise en place au plus haut niveau du programme, et agit en permanence sur toutes les exceptions non traitées.
Oui, c'est une sécurité super. J'ai en effet tout en haut du programme un nombre incroyable de catch, et même des try les uns dans les autres pour utiliser les bons finally. Le finally, au passage, implique il me semble pour être utile de traiter toujours les exceptions.
Les exceptions déclarées mettent en échec ce principe, justement en obligeant une gestion locale des exceptions.
On peut se contenter de récupérer une exception locale reçu d'une couche basse, et de lancer une autre exception, d'un autre type, spéciale à la couche supérieure. Il y a même le sympatique mécanisme iniCause() qui permet de ne pas effacer la mémoire de l'exception.
SL , dans le message <u1wv3mq0l.fsf@nospam.com>, a écrit :
On avait donc tort d'être "structurellement sûr" (il n'y a que vous
pour être structurement sûr :-)) qu'elles ne peuvent pas se produire,
puisque de fait, elles se produisent, non ?
Évidemment.
C'est effectivemetn pire que le départ *si* on "ignore
silencieusement" des exceptions (j'imagine que ça veut dire mettre
un catch vide par exemple), mais ne suffit-il pas de ne *jamais* le
faire et de toujours avoir une politique pour traiter les
exceptions déclarées comme pouvant se produire, même si on est
"sûr" qu'elles ne peuvent pas se produire ?
C'est contraire au principe d'une exception : le principe des
exceptions, c'est qu'il ne faut la traiter que quand elle est
pertinente, et que dans tous les autres cas, elle court-circuite le
flot normal du code, de sorte que son traitement s'hérite suivant la
structure dynamique du programme.
"Court circuiter", d'après ce que je lis plus bas, c'est "être une
exception descendant de java.lang.RuntimeException" et non "être
propagée à l'appelant avec un 'throws' dans la signature de la
méthode" ?
Pourquoi est-ce que le "principe" des exceptions non descendantes de
java.lang.RuntimeException est mauvais ? Il consiste finalement à dire
que ce n'est pas l'utilisateur de la classe qui decide si l'exception
est "pertinente", mais son concepteur : d'une certaine façon, si je
comprends bien la logique, la politique de traitement des exceptions
(le fait de la décider pertinente ou pas) est définis dans l'API, pas
dans son utilisation. En quoi ce n'est pas défendable ?
J'avoue qu'il m'arrive de changer une exception "checkée" en exception
"non checkée", particulièrement en ayant recours au sympathique
IllegalArgumentException ou IllegalStateException, de façon à faire
remonter sans emmerdements une exception d'une couche basse à une
couche haute à travers une couche intermédiaire, de la récupérer dans
la couche haute et de la retransformer en exception "checkée". Je sais
pas si c'est défendable.
Ainsi, la politique que tu évoques peut -- et doit -- être mise en
place au plus haut niveau du programme, et agit en permanence sur
toutes les exceptions non traitées.
Oui, c'est une sécurité super. J'ai en effet tout en haut du programme
un nombre incroyable de catch, et même des try les uns dans les autres
pour utiliser les bons finally. Le finally, au passage, implique il me
semble pour être utile de traiter toujours les exceptions.
Les exceptions déclarées mettent en échec ce principe, justement en
obligeant une gestion locale des exceptions.
On peut se contenter de récupérer une exception locale reçu d'une
couche basse, et de lancer une autre exception, d'un autre type,
spéciale à la couche supérieure. Il y a même le sympatique mécanisme
iniCause() qui permet de ne pas effacer la mémoire de l'exception.
On avait donc tort d'être "structurellement sûr" (il n'y a que vous pour être structurement sûr :-)) qu'elles ne peuvent pas se produire, puisque de fait, elles se produisent, non ?
Évidemment.
C'est effectivemetn pire que le départ *si* on "ignore silencieusement" des exceptions (j'imagine que ça veut dire mettre un catch vide par exemple), mais ne suffit-il pas de ne *jamais* le faire et de toujours avoir une politique pour traiter les exceptions déclarées comme pouvant se produire, même si on est "sûr" qu'elles ne peuvent pas se produire ?
C'est contraire au principe d'une exception : le principe des exceptions, c'est qu'il ne faut la traiter que quand elle est pertinente, et que dans tous les autres cas, elle court-circuite le flot normal du code, de sorte que son traitement s'hérite suivant la structure dynamique du programme.
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ? Il consiste finalement à dire que ce n'est pas l'utilisateur de la classe qui decide si l'exception est "pertinente", mais son concepteur : d'une certaine façon, si je comprends bien la logique, la politique de traitement des exceptions (le fait de la décider pertinente ou pas) est définis dans l'API, pas dans son utilisation. En quoi ce n'est pas défendable ?
J'avoue qu'il m'arrive de changer une exception "checkée" en exception "non checkée", particulièrement en ayant recours au sympathique IllegalArgumentException ou IllegalStateException, de façon à faire remonter sans emmerdements une exception d'une couche basse à une couche haute à travers une couche intermédiaire, de la récupérer dans la couche haute et de la retransformer en exception "checkée". Je sais pas si c'est défendable.
Ainsi, la politique que tu évoques peut -- et doit -- être mise en place au plus haut niveau du programme, et agit en permanence sur toutes les exceptions non traitées.
Oui, c'est une sécurité super. J'ai en effet tout en haut du programme un nombre incroyable de catch, et même des try les uns dans les autres pour utiliser les bons finally. Le finally, au passage, implique il me semble pour être utile de traiter toujours les exceptions.
Les exceptions déclarées mettent en échec ce principe, justement en obligeant une gestion locale des exceptions.
On peut se contenter de récupérer une exception locale reçu d'une couche basse, et de lancer une autre exception, d'un autre type, spéciale à la couche supérieure. Il y a même le sympatique mécanisme iniCause() qui permet de ne pas effacer la mémoire de l'exception.
Nicolas George
JKB , dans le message , a écrit :
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une réfutation.
JKB , dans le message <slrne60tui.d82.knatschke@rayleigh.systella.fr>, a
écrit :
Une fonction qui retourne un int qui n'est pas récupéré par
l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire
que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une
réfutation.
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une réfutation.
Nicolas George
SL , dans le message , a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
SL , dans le message <ufyjjjvre.fsf@nospam.com>, a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une
exception descendant de java.lang.RuntimeException" et non "être
propagée à l'appelant avec un 'throws' dans la signature de la
méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de
java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir
appelé ça exception, et de l'avoir présenté comme le mécanisme normal des
exceptions. C'est en réalité une sorte de type union pour le retour
(_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de
la fonction) automatique.
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
JKB
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une réfutation.
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit d'interdire, le programmeur est assez grand pour savoir ce qu'il fait". Mon expérience me dit que le programmeur est faillible et que par défaut ce type de comportement ne _devrait_ pas être autorisé surtout si l'on veut faire un truc qui ne se bauge pas à la première erreur retournée par le système (style filesystem full pour un fprintf()). Et je mets dans la même catégorie les transtypages automatiques qui sont des sources de merdes incommensurables.
Et en C, ce comportement est d'autant plus pervers qu'il faut chercher dans des appels spéciaux (spécieux ?) les erreurs renoyées par ces fonctions puis les comparer avec errno.h parce que ces trucs sont prétendus portables.
C'est pour cela qu'un langage comme ADA est utilisé, il évite purement et simplement tous ces problèmes qui ne sont pas problèmes d'algorithme mais des problèmes de programmation et de langage utilisé.
JKB
Le 09-05-2006, à propos de
Re: language,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrne60tui.d82.knatschke@rayleigh.systella.fr>, a
écrit :
Une fonction qui retourne un int qui n'est pas récupéré par
l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire
que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une
réfutation.
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit
d'interdire, le programmeur est assez grand pour savoir ce qu'il
fait". Mon expérience me dit que le programmeur est faillible et que
par défaut ce type de comportement ne _devrait_ pas être autorisé
surtout si l'on veut faire un truc qui ne se bauge pas à la première
erreur retournée par le système (style filesystem full pour un
fprintf()). Et je mets dans la même catégorie les transtypages
automatiques qui sont des sources de merdes incommensurables.
Et en C, ce comportement est d'autant plus pervers qu'il faut
chercher dans des appels spéciaux (spécieux ?) les erreurs renoyées
par ces fonctions puis les comparer avec errno.h parce que ces trucs
sont prétendus portables.
C'est pour cela qu'un langage comme ADA est utilisé, il évite
purement et simplement tous ces problèmes qui ne sont pas problèmes
d'algorithme mais des problèmes de programmation et de langage
utilisé.
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée.
Blah. Ce n'est pas en le répétant une fois de plus de manière péremptoire que tu le rends plus vrai. J'ai donné des arguments contre, j'attends une réfutation.
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit d'interdire, le programmeur est assez grand pour savoir ce qu'il fait". Mon expérience me dit que le programmeur est faillible et que par défaut ce type de comportement ne _devrait_ pas être autorisé surtout si l'on veut faire un truc qui ne se bauge pas à la première erreur retournée par le système (style filesystem full pour un fprintf()). Et je mets dans la même catégorie les transtypages automatiques qui sont des sources de merdes incommensurables.
Et en C, ce comportement est d'autant plus pervers qu'il faut chercher dans des appels spéciaux (spécieux ?) les erreurs renoyées par ces fonctions puis les comparer avec errno.h parce que ces trucs sont prétendus portables.
C'est pour cela qu'un langage comme ADA est utilisé, il évite purement et simplement tous ces problèmes qui ne sont pas problèmes d'algorithme mais des problèmes de programmation et de langage utilisé.
JKB
SL
SL , dans le message , a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
SL , dans le message <ufyjjjvre.fsf@nospam.com>, a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une
exception descendant de java.lang.RuntimeException" et non "être
propagée à l'appelant avec un 'throws' dans la signature de la
méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes
de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est
d'avoir appelé ça exception, et de l'avoir présenté comme le
mécanisme normal des exceptions. C'est en réalité une sorte de type
union pour le retour (_local_) d'erreur, avec un mécanisme de
transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
Stéphane Zuckerman
On Tue, 9 May 2006, SL wrote:
SL , dans le message , a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
Sauf qu'une exception n'est pas nécessairement une "erreur". Dans une optique événementielle, "tout" est exception, par exemple : clic, double-clic, événement clavier...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Tue, 9 May 2006, SL wrote:
SL , dans le message <ufyjjjvre.fsf@nospam.com>, a écrit :
"Court circuiter", d'après ce que je lis plus bas, c'est "être une
exception descendant de java.lang.RuntimeException" et non "être
propagée à l'appelant avec un 'throws' dans la signature de la
méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes
de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est
d'avoir appelé ça exception, et de l'avoir présenté comme le
mécanisme normal des exceptions. C'est en réalité une sorte de type
union pour le retour (_local_) d'erreur, avec un mécanisme de
transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).
Sauf qu'une exception n'est pas nécessairement une "erreur". Dans une
optique événementielle, "tout" est exception, par exemple : clic,
double-clic, événement clavier...
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
"Court circuiter", d'après ce que je lis plus bas, c'est "être une exception descendant de java.lang.RuntimeException" et non "être propagée à l'appelant avec un 'throws' dans la signature de la méthode" ?
Oui, c'est ça.
Pourquoi est-ce que le "principe" des exceptions non descendantes de java.lang.RuntimeException est mauvais ?
Le principe ne l'est pas en essence. Ce qui est mauvais, c'est d'avoir appelé ça exception, et de l'avoir présenté comme le mécanisme normal des exceptions. C'est en réalité une sorte de type union pour le retour (_local_) d'erreur, avec un mécanisme de transmission (déclaré au niveau de la fonction) automatique.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
Sauf qu'une exception n'est pas nécessairement une "erreur". Dans une optique événementielle, "tout" est exception, par exemple : clic, double-clic, événement clavier...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Nicolas George
JKB , dans le message , a écrit :
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit d'interdire, le programmeur est assez grand pour savoir ce qu'il fait".
Non, absolument pas, il faudrait songer à apprendre à lire des fois.
La position que je défends, c'est que l'ajout d'une contrainte de vérification du code, si elle permet d'éviter certaines erreurs, va très souvent en causer d'autres, soit aux endroits où il devient nécessaire de la contourner, soit au niveau des déclarations, soit simplement au niveau de la complexité globale du langage.
Dans ces conditions, une contrainte de vérification du code n'est pas forcément mauvaise, mais elle n'est pas forcément bonne comme tu le prétends non plus. Il faut peser le pour et le contre, et évaluer comment ça s'intègre à la cohérence du langage.
Dans le cas qui nous intéresse, rendre obligatoire le test des valeurs de retour en C, ça va (1) causer plein de code inutile, et donc d'erreurs, quand cette vérification n'est pas effectivement nécessaire et, (2) ça ne s'intègre pas du tout dans la logique du langage.
JKB , dans le message <slrne60v2t.d82.knatschke@rayleigh.systella.fr>, a
écrit :
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit
d'interdire, le programmeur est assez grand pour savoir ce qu'il
fait".
Non, absolument pas, il faudrait songer à apprendre à lire des fois.
La position que je défends, c'est que l'ajout d'une contrainte de
vérification du code, si elle permet d'éviter certaines erreurs, va très
souvent en causer d'autres, soit aux endroits où il devient nécessaire de la
contourner, soit au niveau des déclarations, soit simplement au niveau de la
complexité globale du langage.
Dans ces conditions, une contrainte de vérification du code n'est pas
forcément mauvaise, mais elle n'est pas forcément bonne comme tu le prétends
non plus. Il faut peser le pour et le contre, et évaluer comment ça
s'intègre à la cohérence du langage.
Dans le cas qui nous intéresse, rendre obligatoire le test des valeurs de
retour en C, ça va (1) causer plein de code inutile, et donc d'erreurs,
quand cette vérification n'est pas effectivement nécessaire et, (2) ça ne
s'intègre pas du tout dans la logique du langage.
Il n'y a pas de réfutation à avoir. Ta position est "il est interdit d'interdire, le programmeur est assez grand pour savoir ce qu'il fait".
Non, absolument pas, il faudrait songer à apprendre à lire des fois.
La position que je défends, c'est que l'ajout d'une contrainte de vérification du code, si elle permet d'éviter certaines erreurs, va très souvent en causer d'autres, soit aux endroits où il devient nécessaire de la contourner, soit au niveau des déclarations, soit simplement au niveau de la complexité globale du langage.
Dans ces conditions, une contrainte de vérification du code n'est pas forcément mauvaise, mais elle n'est pas forcément bonne comme tu le prétends non plus. Il faut peser le pour et le contre, et évaluer comment ça s'intègre à la cohérence du langage.
Dans le cas qui nous intéresse, rendre obligatoire le test des valeurs de retour en C, ça va (1) causer plein de code inutile, et donc d'erreurs, quand cette vérification n'est pas effectivement nécessaire et, (2) ça ne s'intègre pas du tout dans la logique du langage.
Nicolas George
SL , dans le message , a écrit :
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
Oui, ce n'est pas inutile. Mais le nom est mal choisi et trompeur. À la limite, imagine un langage qui noterait l'addition - et la soustraction + : ces opérations sont extrêmement utiles, mais on peut quand même dire qu'il y a un problème. Nommer exception ce qui ne correspond pas à ce qu'on appelle exception usuellement, c'est du même ordre.
SL , dans le message <uvesfe8ei.fsf@nospam.com>, a écrit :
Je vois, mais je trouve que ça à des avantages pratiques (séparer les
types de retour "normaux" des types dévolus à l'expression d'erreur).
Oui, ce n'est pas inutile. Mais le nom est mal choisi et trompeur. À la
limite, imagine un langage qui noterait l'addition - et la soustraction + :
ces opérations sont extrêmement utiles, mais on peut quand même dire qu'il y
a un problème. Nommer exception ce qui ne correspond pas à ce qu'on appelle
exception usuellement, c'est du même ordre.
Je vois, mais je trouve que ça à des avantages pratiques (séparer les types de retour "normaux" des types dévolus à l'expression d'erreur).
Oui, ce n'est pas inutile. Mais le nom est mal choisi et trompeur. À la limite, imagine un langage qui noterait l'addition - et la soustraction + : ces opérations sont extrêmement utiles, mais on peut quand même dire qu'il y a un problème. Nommer exception ce qui ne correspond pas à ce qu'on appelle exception usuellement, c'est du même ordre.
remy
JKB , dans le message , a
Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne vérifie pas le retour d'une fonction du style fscanf (et encore moins râler parce qu'on ne regarde pas le errno juste après).
Les compilateurs qui râlent quand on ne vérifie pas les retours d'erreur, c'est l'exemple typique de la fausse bonne idée. Un exemple marquant est les exceptions en java : on est obligé de les rattraper même quand on est structurellement sûr qu'elles ne peuvent pas se produire, juste pour les ignorer et faire taire le compilateur. Ce qui fait que le jour où l'exception se produit réellement de manière non-prévue, non seulement le programme n'est pas prêt, mais en plus elle est silencieusement ignorée et propage des résultats aberrants. C'est pire que le départ.
À croire que certains concepteurs de langages n'ont jamais entendu l'histoire de Pierre et le loup.
bonjour public class Main {
public static void main(String[] args) throws Exception {
ZIP z=new ZIP() z.addFichierZip(...);
} }
public class ZIP {
public ZIP(String archive) { .... }
public void addFichierZip(....)throws Exception { } }
simple ?
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
JKB , dans le message <slrne60qos.d82.knatschke@rayleigh.systella.fr>, a
Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne
vérifie pas le retour d'une fonction du style fscanf (et encore
moins râler parce qu'on ne regarde pas le errno juste après).
Les compilateurs qui râlent quand on ne vérifie pas les retours d'erreur,
c'est l'exemple typique de la fausse bonne idée. Un exemple marquant est les
exceptions en java : on est obligé de les rattraper même quand on est
structurellement sûr qu'elles ne peuvent pas se produire, juste pour les
ignorer et faire taire le compilateur. Ce qui fait que le jour où
l'exception se produit réellement de manière non-prévue, non seulement le
programme n'est pas prêt, mais en plus elle est silencieusement ignorée et
propage des résultats aberrants. C'est pire que le départ.
À croire que certains concepteurs de langages n'ont jamais entendu
l'histoire de Pierre et le loup.
bonjour
public class Main {
public static void main(String[] args) throws Exception {
ZIP z=new ZIP()
z.addFichierZip(...);
}
}
public class ZIP {
public ZIP(String archive)
{
....
}
public void addFichierZip(....)throws Exception
{
}
}
simple ?
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne vérifie pas le retour d'une fonction du style fscanf (et encore moins râler parce qu'on ne regarde pas le errno juste après).
Les compilateurs qui râlent quand on ne vérifie pas les retours d'erreur, c'est l'exemple typique de la fausse bonne idée. Un exemple marquant est les exceptions en java : on est obligé de les rattraper même quand on est structurellement sûr qu'elles ne peuvent pas se produire, juste pour les ignorer et faire taire le compilateur. Ce qui fait que le jour où l'exception se produit réellement de manière non-prévue, non seulement le programme n'est pas prêt, mais en plus elle est silencieusement ignorée et propage des résultats aberrants. C'est pire que le départ.
À croire que certains concepteurs de langages n'ont jamais entendu l'histoire de Pierre et le loup.
bonjour public class Main {
public static void main(String[] args) throws Exception {
ZIP z=new ZIP() z.addFichierZip(...);
} }
public class ZIP {
public ZIP(String archive) { .... }
public void addFichierZip(....)throws Exception { } }
simple ?
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Nicolas George
remy , dans le message <e3q17f$9ge$, a écrit :
simple ?
Inutilement verbeux.
remy , dans le message <e3q17f$9ge$1@s1.news.oleane.net>, a écrit :
