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.
J'ai une machine qui a des problèmes de mémoire comme ça, je lui ai dit dans le bios de tourner à 100Mhz au lieu de 133, depuis plus de problème. Avant elle n'arrivait même pas à booter.
Pas de problème pendant 9h30 de test sur la mémoire en 100Mhz, mais je vais recommencer sur 24h.
J'ai une machine qui a des problèmes de mémoire comme ça, je lui ai
dit dans le bios de tourner à 100Mhz au lieu de 133, depuis plus de
problème. Avant elle n'arrivait même pas à booter.
Pas de problème pendant 9h30 de test sur la mémoire en 100Mhz, mais je
vais recommencer sur 24h.
J'ai une machine qui a des problèmes de mémoire comme ça, je lui ai dit dans le bios de tourner à 100Mhz au lieu de 133, depuis plus de problème. Avant elle n'arrivait même pas à booter.
Pas de problème pendant 9h30 de test sur la mémoire en 100Mhz, mais je vais recommencer sur 24h.
JKB
Le 09-05-2006, à propos de Re: language, Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Tue, 9 May 2006, JKB wrote:
Le 09-05-2006, à propos de Re: language, Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Sat, 6 May 2006, JKB wrote:
Montre-moi un seul de tes programmes écrit en C, que je le critique. Je ne connais pas beaucoup de personnes qui récupèrent les codes renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le nombre de caractères imprimés n'est pas souvent très intéressant à connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il est utile de savoir par exemple que tout ce qu'on voulait écrire dans un fichier a bien été écrit.
Bien sûr. Mais bon, si l'on est un minimum sérieux pour faire du C, on lit la FAQ de clc ou fclc, et on apprend tout un tas de trucs intéressants, voire on pose des questions là-bas, on se fait un peu maltraiter au début parce qu'on a oublié de vérifier le retour des fonctions (et généralement c'est signalé par le compilateur...), puis on progresse.
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).
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un fichier à cause d'un bug bien avant dans le programme en question et lorsqu'on essaye de relire, le truc se casse la figure.
Nous sommes donc d'accord : ce n'est pas exactement la faute au printf, mais à un bug plus en amont. C'est ce que je voulais dire : un printf qui "plante" un programme n'est généralement que le symptôme.
Et si le compilo interdisait d'utiliser une telle fonction sans _au moins_ que l'utilisateur récupère l'entier en question ?
JKB
Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Tue, 9 May 2006, JKB wrote:
Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Sat, 6 May 2006, JKB wrote:
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il
est utile de savoir par exemple que tout ce qu'on voulait écrire
dans un fichier a bien été écrit.
Bien sûr. Mais bon, si l'on est un minimum sérieux pour faire du C, on lit
la FAQ de clc ou fclc, et on apprend tout un tas de trucs intéressants,
voire on pose des questions là-bas, on se fait un peu maltraiter au début
parce qu'on a oublié de vérifier le retour des fonctions (et généralement
c'est signalé par le compilateur...), puis on progresse.
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).
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
fichier à cause d'un bug bien avant dans le programme en question et
lorsqu'on essaye de relire, le truc se casse la figure.
Nous sommes donc d'accord : ce n'est pas exactement la faute au printf,
mais à un bug plus en amont. C'est ce que je voulais dire : un printf qui
"plante" un programme n'est généralement que le symptôme.
Et si le compilo interdisait d'utiliser une telle fonction sans _au
moins_ que l'utilisateur récupère l'entier en question ?
Le 09-05-2006, à propos de Re: language, Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Tue, 9 May 2006, JKB wrote:
Le 09-05-2006, à propos de Re: language, Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Sat, 6 May 2006, JKB wrote:
Montre-moi un seul de tes programmes écrit en C, que je le critique. Je ne connais pas beaucoup de personnes qui récupèrent les codes renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le nombre de caractères imprimés n'est pas souvent très intéressant à connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il est utile de savoir par exemple que tout ce qu'on voulait écrire dans un fichier a bien été écrit.
Bien sûr. Mais bon, si l'on est un minimum sérieux pour faire du C, on lit la FAQ de clc ou fclc, et on apprend tout un tas de trucs intéressants, voire on pose des questions là-bas, on se fait un peu maltraiter au début parce qu'on a oublié de vérifier le retour des fonctions (et généralement c'est signalé par le compilateur...), puis on progresse.
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).
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un fichier à cause d'un bug bien avant dans le programme en question et lorsqu'on essaye de relire, le truc se casse la figure.
Nous sommes donc d'accord : ce n'est pas exactement la faute au printf, mais à un bug plus en amont. C'est ce que je voulais dire : un printf qui "plante" un programme n'est généralement que le symptôme.
Et si le compilo interdisait d'utiliser une telle fonction sans _au moins_ que l'utilisateur récupère l'entier en question ?
JKB
Nicolas George
JKB , dans le message , a écrit :
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.
JKB , dans le message <slrne60qos.d82.knatschke@rayleigh.systella.fr>, a
écrit :
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.
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.
JKB
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
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.
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
JKB
Le 09-05-2006, à propos de
Re: language,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrne60qos.d82.knatschke@rayleigh.systella.fr>, a
écrit :
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.
Je maintiens qu'un compilo devrait râler sans vergogne contre ce
genre de trucs quitte à avoir une option pour ignorer ces erreurs
lorsqu'on sait _exactement_ ce que l'on fait.
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
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.
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
JKB
Nicolas George
Stéphane Zuckerman , dans le message , a écrit :
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur de type avec un programme "stuck" à cause de ça. Et c'est franchement un mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible avec les versions précédentes, et de n'utiliser que des bibliothèques prévues en conséquence. Là, on commence à avoir quelque chose de vaguement prévisible statiquement. Sinon, ce qui est le cas de l'immense majorité des développeurs java, on a des casts vers et depuis Object, c'est exactement le même niveau de fiabilité que le C, la seule différence est l'aspect de la sanction en cas d'erreur.
Stéphane Zuckerman , dans le message
<Pine.OSF.4.64.0605091018190.365039@vega.utc.fr>, a écrit :
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
de type avec un programme "stuck" à cause de ça. Et c'est franchement un
mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible
avec les versions précédentes, et de n'utiliser que des bibliothèques
prévues en conséquence. Là, on commence à avoir quelque chose de vaguement
prévisible statiquement. Sinon, ce qui est le cas de l'immense majorité des
développeurs java, on a des casts vers et depuis Object, c'est exactement le
même niveau de fiabilité que le C, la seule différence est l'aspect de la
sanction en cas d'erreur.
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur de type avec un programme "stuck" à cause de ça. Et c'est franchement un mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible avec les versions précédentes, et de n'utiliser que des bibliothèques prévues en conséquence. Là, on commence à avoir quelque chose de vaguement prévisible statiquement. Sinon, ce qui est le cas de l'immense majorité des développeurs java, on a des casts vers et depuis Object, c'est exactement le même niveau de fiabilité que le C, la seule différence est l'aspect de la sanction en cas d'erreur.
Nicolas George
JKB , dans le message , a écrit :
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un programme de manière suffisante pour déterminer dans quel cas les tests sont nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout ce qui reste ce sont des heuristiques.
Ce que je dis, c'est que quand ces heuristiques ne disent pas que le test est nécessaire de manière _très_ fiable, il vaut mieux ne rien mettre, parce que les structures pour juste faire taire le compilo sont très souvent largement pires que les erreurs elles-mêmes.
JKB , dans le message <slrne60s81.d82.knatschke@rayleigh.systella.fr>, a
écrit :
Je maintiens qu'un compilo devrait râler sans vergogne contre ce
genre de trucs quitte à avoir une option pour ignorer ces erreurs
lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup
d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un
programme de manière suffisante pour déterminer dans quel cas les tests sont
nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout
ce qui reste ce sont des heuristiques.
Ce que je dis, c'est que quand ces heuristiques ne disent pas que le test
est nécessaire de manière _très_ fiable, il vaut mieux ne rien mettre, parce
que les structures pour juste faire taire le compilo sont très souvent
largement pires que les erreurs elles-mêmes.
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un programme de manière suffisante pour déterminer dans quel cas les tests sont nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout ce qui reste ce sont des heuristiques.
Ce que je dis, c'est que quand ces heuristiques ne disent pas que le test est nécessaire de manière _très_ fiable, il vaut mieux ne rien mettre, parce que les structures pour juste faire taire le compilo sont très souvent largement pires que les erreurs elles-mêmes.
SL
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
[...]
Ce qui fait que le jour où l'exception se produit réellement de manière non-prévue,
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 ?
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.
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 ?
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
[...]
Ce qui fait que le jour où l'exception se produit réellement de
manière non-prévue,
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 ?
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.
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 ?
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
[...]
Ce qui fait que le jour où l'exception se produit réellement de manière non-prévue,
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 ?
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.
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 ?
Nicolas George
SL , dans le message , 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.
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. C'est un fonctionnement sain et intelligent.
Les exceptions déclarées mettent en échec ce principe, justement en obligeant une gestion locale des exceptions.
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.
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. C'est un fonctionnement sain et intelligent.
Les exceptions déclarées mettent en échec ce principe, justement en
obligeant une gestion locale des exceptions.
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.
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. C'est un fonctionnement sain et intelligent.
Les exceptions déclarées mettent en échec ce principe, justement en obligeant une gestion locale des exceptions.
SL
Stéphane Zuckerman , dans le message , a écrit :
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur de type avec un programme "stuck" à cause de ça. Et c'est franchement un mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible avec les versions précédentes,
Je trouve complètement ahurissant le niveau d'incompatibilité entre java 5 et java 1.4. Même quelque chose d'aussi incroyablement trivial que récupérer la valeur d'une variable d'environnement ne *peut pas* être fait de la même façon en java 1.4 et 5, où alors je suis complètement à la masse. Il faut utiliser System.getenv() qui est remis en java 5 mais qui est deprecated en java 1.4, et qui fait se plaindre le compilateur.
Je ne parle pas le l'emmerdement absolument démentiel que produit l'inclusion de jaxp dans la distribution standard, ce qui fait que depuis les factory il est impossible de contrôler les processeurs XML retournés, alors qu'ils sont parfois incompatibles. Je m'arrache les cheveux là dessus.
Stéphane Zuckerman , dans le message
<Pine.OSF.4.64.0605091018190.365039@vega.utc.fr>, a écrit :
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
de type avec un programme "stuck" à cause de ça. Et c'est franchement un
mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible
avec les versions précédentes,
Je trouve complètement ahurissant le niveau d'incompatibilité entre
java 5 et java 1.4. Même quelque chose d'aussi incroyablement trivial
que récupérer la valeur d'une variable d'environnement ne *peut pas*
être fait de la même façon en java 1.4 et 5, où alors je suis
complètement à la masse. Il faut utiliser System.getenv() qui est
remis en java 5 mais qui est deprecated en java 1.4, et qui fait se
plaindre le compilateur.
Je ne parle pas le l'emmerdement absolument démentiel que produit
l'inclusion de jaxp dans la distribution standard, ce qui fait que
depuis les factory il est impossible de contrôler les processeurs XML
retournés, alors qu'ils sont parfois incompatibles. Je m'arrache les
cheveux là dessus.
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur de type avec un programme "stuck" à cause de ça. Et c'est franchement un mieux par rapport à C.
À condition de parler de java 1.5, et le programmer de manière incompatible avec les versions précédentes,
Je trouve complètement ahurissant le niveau d'incompatibilité entre java 5 et java 1.4. Même quelque chose d'aussi incroyablement trivial que récupérer la valeur d'une variable d'environnement ne *peut pas* être fait de la même façon en java 1.4 et 5, où alors je suis complètement à la masse. Il faut utiliser System.getenv() qui est remis en java 5 mais qui est deprecated en java 1.4, et qui fait se plaindre le compilateur.
Je ne parle pas le l'emmerdement absolument démentiel que produit l'inclusion de jaxp dans la distribution standard, ce qui fait que depuis les factory il est impossible de contrôler les processeurs XML retournés, alors qu'ils sont parfois incompatibles. Je m'arrache les cheveux là dessus.
JKB
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un programme de manière suffisante pour déterminer dans quel cas les tests sont nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout ce qui reste ce sont des heuristiques.
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée. Si on veut un tel truc, on introduit des paramètres optionnels façon Fortran et on n'en parle plus. Une fonction retourne quelque chose ou ne retourne rien.
JKB
Le 09-05-2006, à propos de
Re: language,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrne60s81.d82.knatschke@rayleigh.systella.fr>, a
écrit :
Je maintiens qu'un compilo devrait râler sans vergogne contre ce
genre de trucs quitte à avoir une option pour ignorer ces erreurs
lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup
d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un
programme de manière suffisante pour déterminer dans quel cas les tests sont
nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout
ce qui reste ce sont des heuristiques.
Une fonction qui retourne un int qui n'est pas récupéré par
l'appelant _doit_ être signalée. Si on veut un tel truc, on
introduit des paramètres optionnels façon Fortran et on n'en parle
plus. Une fonction retourne quelque chose ou ne retourne rien.
Le 09-05-2006, à propos de Re: language, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je maintiens qu'un compilo devrait râler sans vergogne contre ce genre de trucs quitte à avoir une option pour ignorer ces erreurs lorsqu'on sait _exactement_ ce que l'on fait.
Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
Il n'y a pas à en sortir : un compilateur ne peut pas comprendre un programme de manière suffisante pour déterminer dans quel cas les tests sont nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout ce qui reste ce sont des heuristiques.
Une fonction qui retourne un int qui n'est pas récupéré par l'appelant _doit_ être signalée. Si on veut un tel truc, on introduit des paramètres optionnels façon Fortran et on n'en parle plus. Une fonction retourne quelque chose ou ne retourne rien.
