Microsoft semble reconnaître que Java permet de développer plus
rapidement que C# et qu'il y a moins de failles de sécurité dans Java
que dans .net :
http://dsi.silicon.fr/nouveautes/microsoft-java-forever%E2%80%A6-1366
Non. Va jusqu'au bout de ton raisonnement. Cela implique de récupérer le code d'erreur localement, puis de traiter ce qu'il faut localement, puis de remonter l'erreur (soit avec un code d'erreur, soit avec une exception et un magnifique throw) à la fonction appelante, et ainsi récursivement jusqu'à un point où tu peux prendre ta décision sur le traitement à apporter. Je n'ai _jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu. La plupart du temps, tu as un try/catch avec un gros machin pas net dedans qui récupère toutes les exceptions qui passent, se contrefichant éperdument de tout ce qu'il faudrait récupérer correctement.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris <aeris@imirhil.fr> écrivait :
Le 18/06/2011 19:50, JKB a écrit :
Pas exactement. Mais si tu ne vois pas la différence, tant pis.
J'ai très bien compris.
Rien ne t'empèche de traiter localement ta libération de mémoire puis de
remonter l'erreur pour faire la reprise.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce qu'il faut
localement, puis de remonter l'erreur (soit avec un code d'erreur,
soit avec une exception et un magnifique throw) à la fonction appelante,
et ainsi récursivement jusqu'à un point où tu peux prendre ta décision
sur le traitement à apporter. Je n'ai _jamais_ vu un code Java (ou C++
d'ailleurs) fonctionner comme ça. Je ne dis pas que ça n'existe pas,
simplement que je n'en ai jamais vu. La plupart du temps, tu as un
try/catch avec un gros machin pas net dedans qui récupère toutes les
exceptions qui passent, se contrefichant éperdument de tout ce qu'il
faudrait récupérer correctement.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Non. Va jusqu'au bout de ton raisonnement. Cela implique de récupérer le code d'erreur localement, puis de traiter ce qu'il faut localement, puis de remonter l'erreur (soit avec un code d'erreur, soit avec une exception et un magnifique throw) à la fonction appelante, et ainsi récursivement jusqu'à un point où tu peux prendre ta décision sur le traitement à apporter. Je n'ai _jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu. La plupart du temps, tu as un try/catch avec un gros machin pas net dedans qui récupère toutes les exceptions qui passent, se contrefichant éperdument de tout ce qu'il faudrait récupérer correctement.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
Aéris , dans le message <4dfce7df$0$20025$, a écrit :
Mais mes outils Java me permettent de détecter ce genre de conneries très rapidement.
J'incrois. Le fait de savoir si c'est effectivement une connerie ou pas demande la compréhension du code, aucun outil ne peut le faire à la place d'un programmeur compétent.
Aéris , dans le message <4dfce7df$0$20025$426a34cc@news.free.fr>, a
écrit :
Mais mes outils Java me permettent de détecter ce genre de conneries
très rapidement.
J'incrois. Le fait de savoir si c'est effectivement une connerie ou pas
demande la compréhension du code, aucun outil ne peut le faire à la place
d'un programmeur compétent.
Aéris , dans le message <4dfce7df$0$20025$, a écrit :
Mais mes outils Java me permettent de détecter ce genre de conneries très rapidement.
J'incrois. Le fait de savoir si c'est effectivement une connerie ou pas demande la compréhension du code, aucun outil ne peut le faire à la place d'un programmeur compétent.
Nicolas George
Aéris , dans le message <4dfce836$0$20025$, a écrit :
Je ne vois vraiment pas d'exemple justifiable de ce type de chose? Si tu peux éclairer ma lanterne, je suis preneur =)
Tu fais comment, sans compilation conditionnelle ?
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 18/06/2011 20:42, Nicolas George a écrit :
Le fait de savoir si c'est effectivement une connerie ou pas demande la compréhension du code, aucun outil ne peut le faire à la place d'un programmeur compétent.
Oui mais un catch-all est rarement une bonne idée et même sans compréhension du code, 99% de chance que le code doit être corrigé !
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Le fait de savoir si c'est effectivement une connerie ou pas
demande la compréhension du code, aucun outil ne peut le faire à la place
d'un programmeur compétent.
Oui mais un catch-all est rarement une bonne idée et même sans
compréhension du code, 99% de chance que le code doit être corrigé !
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Le fait de savoir si c'est effectivement une connerie ou pas demande la compréhension du code, aucun outil ne peut le faire à la place d'un programmeur compétent.
Oui mais un catch-all est rarement une bonne idée et même sans compréhension du code, 99% de chance que le code doit être corrigé !
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Tu fais comment, sans compilation conditionnelle ?
Euh… Là comme ça, je considère ça comme du code de goret. Ça va t'obliger à trainer des if CONF_AVFILTER partout dans le code… 2 types d'objet avec héritage aurait été hautement plus propre et modulable !
C'est l'exemple même de code qui va te générer des tonnes d'effets de bords à la con à la moindre modif.
Du genre le « logfile » qui se pointe dans le « if » suite à une évolution fonctionnelle et qui va se mettre à péter dans TOUT le reste du code qui continue à y accéder car y reste en dehors du « if ».
Ou encore l'ajout d'une nouvelle alternative à CONFIG_AVFILTER du genre #if CONFIG_AVFILTER #if CONFIG_FOO int bar; #endif #endif qui rend le code de plus en plus complexe et nécessite à chaque fois de reprendre TOUTES les méthodes manipulant ce type, et donc potentiellement à injecter des régressions dans du code qui était 100% fonctionnel. TOUT le plan de test est à repasser, y compris sur les fonctionnalitées V-1
Alors qu'avec de la POO et de l'héritage, le nouveau type se contente d'appeler du code déjà testé + la nouveauté.
class Bar : Foo { int bar;
doIt() { super.doIt(); // garanti correct et déjà testé doBar(bar); // seule partie à tester } }
Seules les fonctionnalitée V+1 sont à tester et les V-1 n'ont absolument aucun risque d'être impactées.
Et je ne vois pas le rapport avec la gestion de dépendance…
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Tu fais comment, sans compilation conditionnelle ?
Euh…
Là comme ça, je considère ça comme du code de goret.
Ça va t'obliger à trainer des if CONF_AVFILTER partout dans le code…
2 types d'objet avec héritage aurait été hautement plus propre et
modulable !
C'est l'exemple même de code qui va te générer des tonnes d'effets de
bords à la con à la moindre modif.
Du genre le « logfile » qui se pointe dans le « if » suite à une
évolution fonctionnelle et qui va se mettre à péter dans TOUT le reste
du code qui continue à y accéder car y reste en dehors du « if ».
Ou encore l'ajout d'une nouvelle alternative à CONFIG_AVFILTER du genre
#if CONFIG_AVFILTER
#if CONFIG_FOO
int bar;
#endif
#endif
qui rend le code de plus en plus complexe et nécessite à chaque fois de
reprendre TOUTES les méthodes manipulant ce type, et donc
potentiellement à injecter des régressions dans du code qui était 100%
fonctionnel. TOUT le plan de test est à repasser, y compris sur les
fonctionnalitées V-1
Alors qu'avec de la POO et de l'héritage, le nouveau type se contente
d'appeler du code déjà testé + la nouveauté.
class Bar : Foo {
int bar;
doIt() {
super.doIt(); // garanti correct et déjà testé
doBar(bar); // seule partie à tester
}
}
Seules les fonctionnalitée V+1 sont à tester et les V-1 n'ont absolument
aucun risque d'être impactées.
Et je ne vois pas le rapport avec la gestion de dépendance…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Tu fais comment, sans compilation conditionnelle ?
Euh… Là comme ça, je considère ça comme du code de goret. Ça va t'obliger à trainer des if CONF_AVFILTER partout dans le code… 2 types d'objet avec héritage aurait été hautement plus propre et modulable !
C'est l'exemple même de code qui va te générer des tonnes d'effets de bords à la con à la moindre modif.
Du genre le « logfile » qui se pointe dans le « if » suite à une évolution fonctionnelle et qui va se mettre à péter dans TOUT le reste du code qui continue à y accéder car y reste en dehors du « if ».
Ou encore l'ajout d'une nouvelle alternative à CONFIG_AVFILTER du genre #if CONFIG_AVFILTER #if CONFIG_FOO int bar; #endif #endif qui rend le code de plus en plus complexe et nécessite à chaque fois de reprendre TOUTES les méthodes manipulant ce type, et donc potentiellement à injecter des régressions dans du code qui était 100% fonctionnel. TOUT le plan de test est à repasser, y compris sur les fonctionnalitées V-1
Alors qu'avec de la POO et de l'héritage, le nouveau type se contente d'appeler du code déjà testé + la nouveauté.
class Bar : Foo { int bar;
doIt() { super.doIt(); // garanti correct et déjà testé doBar(bar); // seule partie à tester } }
Seules les fonctionnalitée V+1 sont à tester et les V-1 n'ont absolument aucun risque d'être impactées.
Et je ne vois pas le rapport avec la gestion de dépendance…
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
compréhension du code, 99% de chance que le code doit être corrigé !
Et 99,7% des statistiques de ce genre sont fantaisistes.
Si tu préfères, sans même aller voir ce que cela fait réellement, j'imposerai que ce code soit dégagé ! La probabilité qu'il soit réellement utile (sachant en plus qu'on peut faire autrement) est trop faible pour que tu en ais réellement l'utilité dans toute ta carrière.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
compréhension du code, 99% de chance que le code doit être corrigé !
Et 99,7% des statistiques de ce genre sont fantaisistes.
Si tu préfères, sans même aller voir ce que cela fait réellement,
j'imposerai que ce code soit dégagé !
La probabilité qu'il soit réellement utile (sachant en plus qu'on peut
faire autrement) est trop faible pour que tu en ais réellement l'utilité
dans toute ta carrière.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
compréhension du code, 99% de chance que le code doit être corrigé !
Et 99,7% des statistiques de ce genre sont fantaisistes.
Si tu préfères, sans même aller voir ce que cela fait réellement, j'imposerai que ce code soit dégagé ! La probabilité qu'il soit réellement utile (sachant en plus qu'on peut faire autrement) est trop faible pour que tu en ais réellement l'utilité dans toute ta carrière.
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Aéris , dans le message <4dfcf9a7$0$18558$, a écrit :
Si tu préfères, sans même aller voir ce que cela fait réellement, j'imposerai que ce code soit dégagé ! La probabilité qu'il soit réellement utile (sachant en plus qu'on peut faire autrement) est trop faible pour que tu en ais réellement l'utilité dans toute ta carrière.
Tu ne connais pas la situation, mais tu as déjà une certitude sur la réponse...
Aéris , dans le message <4dfcf9a7$0$18558$426a74cc@news.free.fr>, a
écrit :
Si tu préfères, sans même aller voir ce que cela fait réellement,
j'imposerai que ce code soit dégagé !
La probabilité qu'il soit réellement utile (sachant en plus qu'on peut
faire autrement) est trop faible pour que tu en ais réellement l'utilité
dans toute ta carrière.
Tu ne connais pas la situation, mais tu as déjà une certitude sur la
réponse...
Aéris , dans le message <4dfcf9a7$0$18558$, a écrit :
Si tu préfères, sans même aller voir ce que cela fait réellement, j'imposerai que ce code soit dégagé ! La probabilité qu'il soit réellement utile (sachant en plus qu'on peut faire autrement) est trop faible pour que tu en ais réellement l'utilité dans toute ta carrière.
Tu ne connais pas la situation, mais tu as déjà une certitude sur la réponse...
Nicolas George
Aéris , dans le message <4dfcf90f$0$18558$, a écrit :
Alors qu'avec de la POO et de l'héritage, le nouveau type se contente d'appeler du code déjà testé + la nouveauté.
Montre-nous tout le code nécessaire, en particulier celui où on définit les objets et celui où on les instancie, sans compilation conditionnelle.
Aéris , dans le message <4dfcf90f$0$18558$426a74cc@news.free.fr>, a
écrit :
Alors qu'avec de la POO et de l'héritage, le nouveau type se contente
d'appeler du code déjà testé + la nouveauté.
Montre-nous tout le code nécessaire, en particulier celui où on définit les
objets et celui où on les instancie, sans compilation conditionnelle.
