Non mais il va creuser un peu et utiliser la fonctionnalité sans forcément voir tous les ecueils qui se cachent derrière.
En même temps partout la fonctionnalité est documentée en indiquant l'utilité des struct :
- avoir un type "primitif" personnalisé alloué sur la pile, qui contient juste quelques données (par exemple un point avec 2 entiers pour les coordonnées) : dans ce genre de cas c'est en général bénéfique question perf et surtout place mémoire.
- avoir un mapping d'une structure C : de ce point de vu c'est comme si je te disais que les API JNI sont très dangereux parcqu'ils permettent de faire des conneries. Ben c'est pareil pour les pointeurs : les concepteurs de C# ont préféré appeler un chat un chat, un pointeur est un pointeur et pas besoin de créer un truc bancale, non portable et qui cache à l'utilisateur des manque flagrant de sécurité.
Pour les exceptions non trappées ils sont juste parti d'un constat simple : la plupart des dév finissent par faire des throw Exception (je dis pas que c'est intelligent). De plus les concepteurs de Java se sont bien apercu que c'était vite lourd de trapper toutes les exceptions : la preuve les exception "standards" n'ont pas l'obligation d'être trappées.
Et puis c'est aussi une question de design : les exceptions ne font pas parti de la signature de la méthode. En cas de version 1.1 d'une classe qui rajoute un test pouvant lever une exception (un cas non prévu dans la version 1.0), ben hop tu casses potentiellement tous les clients qui utilisent ta classe, à moins de tous les recompiler car seul le compilateur vérifie que les exceptions sont bien trappées.
Bref c'est bancale, lourd, et au final souvent mal utilisé.
Dans certains cas je trouve au contraire C# beaucoup plus robuste : d'abord vis à vis des exceptions le comportement sera toujours celui attendu (je l'ai montré plus haut en Java ce n'est pas le cas, c'est même pas documenté). Le versionning en C# est beaucoup plus fin, précis et vérifiable. Les pointeurs en C# permettent au compilateur d'effectuer des vérifications (ce ne sont pas des bêtes pointeurs C++) alors que JNI tent à cacher tout cela, sans résoudre le moindre problème. Par défaut en Java les méthodes sont virtuelles : je trouve cela dangereux car bien souvent les développeurs oublient les "final", sans parler d'éventuel problème de perf (mais c'est relatif), c'est surtout offrir la possibilité à une classe dérivée de modifier le comportement de la classe initiale alors que ce n'était pas forcement prévu.
Pour les generics idem, le compilo Java fait son taf mais dans un scénario d'introspection tout se barre en couille puisqu'on retrouve le type generique "object" partout, permettant de faire tout et n'importe quoi.
Donc tu vois pour moi c'est l'inverse, C# est plus robuste que Java ;)
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
En même temps partout la fonctionnalité est documentée en indiquant l'utilité des struct :
- avoir un type "primitif" personnalisé alloué sur la pile, qui contient juste quelques données (par exemple un point avec 2 entiers pour les coordonnées) : dans ce genre de cas c'est en général bénéfique question perf et surtout place mémoire.
- avoir un mapping d'une structure C : de ce point de vu c'est comme si je te disais que les API JNI sont très dangereux parcqu'ils permettent de faire des conneries. Ben c'est pareil pour les pointeurs : les concepteurs de C# ont préféré appeler un chat un chat, un pointeur est un pointeur et pas besoin de créer un truc bancale, non portable et qui cache à l'utilisateur des manque flagrant de sécurité.
Pour les exceptions non trappées ils sont juste parti d'un constat simple : la plupart des dév finissent par faire des throw Exception (je dis pas que c'est intelligent). De plus les concepteurs de Java se sont bien apercu que c'était vite lourd de trapper toutes les exceptions : la preuve les exception "standards" n'ont pas l'obligation d'être trappées.
Et puis c'est aussi une question de design : les exceptions ne font pas parti de la signature de la méthode. En cas de version 1.1 d'une classe qui rajoute un test pouvant lever une exception (un cas non prévu dans la version 1.0), ben hop tu casses potentiellement tous les clients qui utilisent ta classe, à moins de tous les recompiler car seul le compilateur vérifie que les exceptions sont bien trappées.
Bref c'est bancale, lourd, et au final souvent mal utilisé.
Dans certains cas je trouve au contraire C# beaucoup plus robuste : d'abord vis à vis des exceptions le comportement sera toujours celui attendu (je l'ai montré plus haut en Java ce n'est pas le cas, c'est même pas documenté). Le versionning en C# est beaucoup plus fin, précis et vérifiable. Les pointeurs en C# permettent au compilateur d'effectuer des vérifications (ce ne sont pas des bêtes pointeurs C++) alors que JNI tent à cacher tout cela, sans résoudre le moindre problème. Par défaut en Java les méthodes sont virtuelles : je trouve cela dangereux car bien souvent les développeurs oublient les "final", sans parler d'éventuel problème de perf (mais c'est relatif), c'est surtout offrir la possibilité à une classe dérivée de modifier le comportement de la classe initiale alors que ce n'était pas forcement prévu.
Pour les generics idem, le compilo Java fait son taf mais dans un scénario d'introspection tout se barre en couille puisqu'on retrouve le type generique "object" partout, permettant de faire tout et n'importe quoi.
Donc tu vois pour moi c'est l'inverse, C# est plus robuste que Java ;)
Au fait un article qui devrait t'intéresser :
Les generics en C#, Java, C++ comparés :
http://www.artima.com/intv/generics.html(...)
Pourquoi pas d'exception trappées en C# par rapport à Java :
http://www.artima.com/intv/handcuffs.html(...)