Tout ce que je voulais dire, c'est que si (par exemple hein) en C++ on a décidé de proposer les deux méthodes, ce n'est pas pour rien. Il y a des fois où la performance *est* importante, et les exceptions se mettent en travers. Et au final, la réflexion concernait le fait qu'il n'y a pas de solution unique, et que le « tout exception » n'est pas forcément quelque chose de voulu ou de souhaitable. Tout dépend l'état d'esprit dans lequel on programme.
[à propos des exceptions] Certes, ca va ralentir un peu les perfs.
Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).
Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.
La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)
Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)
[^] # Re: Code le toi même
Posté par lasher . En réponse à la dépêche Sortie de Moonlight 1.0. Évalué à 3.
[à propos des exceptions] Certes, ca va ralentir un peu les perfs.
Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).
Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.
La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)
Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)