J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
Ah ben voila, quelle logique ! Une doc peut avoir des erreurs, donc en toute logique : il ne faut jamais utiliser la doc !
Tu sais qu'un compilateur peut avoir des bugs, pourquoi tu en utilises un alors ?
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Super, ca ne change absolument RIEN au fait que la doc est utile, qu'elle donne plein d'informations correctes, et qu'elle evite de faire des erreurs.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
C'est pas ce que je t'ai demande, je t'ai demande en quoi je devrais suivre tes dires plutot que ceux des devs du kernel Linux ou de chez Microsoft. Tu as quoi comme experience de gros developpements de qualite et a succes qu'ils n'ont pas ?
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Tu as faux sur toute la ligne. Je dis bien, toute la ligne, et j'ai des millions de lignes de code presentes sur 1 milliard de machines qui le prouvent. Je t'ai meme presente plus haut pourquoi il n'y a pas besoin de connaitre toutes les erreurs pour pouvoir les gerer.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
Ah ben oui, parce que le compilateur est sense savoir comment tu veux gerer une erreur ? Le compilateur est meme sense savoir ce qu'est une erreur ? Serieux, tu developpes vraiment professionellement ?
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Vraiment ? Tu connais les problemes du traitement en exceptions ? Sont cout en performance, la difficulte d'eviter des leaks et autres quand l'exception se produit apres que tu aies alloue des ressources, pris des locks, etc… ?
Le systeme par exception n'a pas vraiment plus d'avantages ni d'inconvenients, c'est une autre approche simplement.
Ton 'truc' ou les erreurs que tu ne connais pas sont remontees c'est exactement ce que je t'ai montre plus haut en C. Mon code fait exactement la meme chose : une erreur inconnue est remontee aussi.
Et non le compilo ne fait pas tout le travail ingrat, le compilo ne sait pas liberer des ressources prises avant l'exception, il ne sait pas liberer un lock, etc…
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
Un compilateur peut faire des erreurs (et oui, ca existe), mais en plus, un compilateur ne sait pas gerer les erreurs, du tout.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 10.
J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
Ah ben voila, quelle logique ! Une doc peut avoir des erreurs, donc en toute logique : il ne faut jamais utiliser la doc !
Tu sais qu'un compilateur peut avoir des bugs, pourquoi tu en utilises un alors ?
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Super, ca ne change absolument RIEN au fait que la doc est utile, qu'elle donne plein d'informations correctes, et qu'elle evite de faire des erreurs.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
C'est pas ce que je t'ai demande, je t'ai demande en quoi je devrais suivre tes dires plutot que ceux des devs du kernel Linux ou de chez Microsoft. Tu as quoi comme experience de gros developpements de qualite et a succes qu'ils n'ont pas ?
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Tu as faux sur toute la ligne. Je dis bien, toute la ligne, et j'ai des millions de lignes de code presentes sur 1 milliard de machines qui le prouvent. Je t'ai meme presente plus haut pourquoi il n'y a pas besoin de connaitre toutes les erreurs pour pouvoir les gerer.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
Ah ben oui, parce que le compilateur est sense savoir comment tu veux gerer une erreur ? Le compilateur est meme sense savoir ce qu'est une erreur ? Serieux, tu developpes vraiment professionellement ?
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Vraiment ? Tu connais les problemes du traitement en exceptions ? Sont cout en performance, la difficulte d'eviter des leaks et autres quand l'exception se produit apres que tu aies alloue des ressources, pris des locks, etc… ?
Le systeme par exception n'a pas vraiment plus d'avantages ni d'inconvenients, c'est une autre approche simplement.
Ton 'truc' ou les erreurs que tu ne connais pas sont remontees c'est exactement ce que je t'ai montre plus haut en C. Mon code fait exactement la meme chose : une erreur inconnue est remontee aussi.
Et non le compilo ne fait pas tout le travail ingrat, le compilo ne sait pas liberer des ressources prises avant l'exception, il ne sait pas liberer un lock, etc…
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
Un compilateur peut faire des erreurs (et oui, ca existe), mais en plus, un compilateur ne sait pas gerer les erreurs, du tout.