Pour les exceptions non trappées, je préfère que le compilo me prévienne qu'une méthode est suceptible de jeter une exception plutôt que d'aller le voir dans la doc ou de m'en appercevoir au runtime
Sauf que bien entendu toutes les exceptions "standards" sont "ignorées" par le compilo : "InvalidCastException", "NullPointerException", "OutOfMemoryException", etc. C'es les plus courantes et le compilo te diras jamais rien.
Si une librairie tierce change le prototype d'une méthode, je préfère être prévenu par mon compilo parce que la responsabilité, au final, elle est pour ma pomme et bien entendu je vais recompiler avec cette nouvelle bibliothèque!
oué mais si tu patches bêtement la lib sans recompiler ton appli ? Genre le client met à jour son OS et les libs qui vont bien, sans bien entendu recompiler les appli : une lib introduit une exception, boum le runtime Java ne voit pas la différence et casse tout. En C# t'as pas le problème grâce à la gestion du versionning qui détectera ce genre de différence.
Les maîtres mots dans mon secteur sont robustesse et maintenabilité.
Les miens aussi. J'ai essayé de montré assez clairement que C# introduisait pas mal de robustesse. Question maintenance je penses qu'on sera d'accord pour dire que .NET/Mono est bien mieux que Java pour ca : le versionning est un des plus complets en .NET/Mono alors qu'il est quasiment absent de Java.
Pour les perfs je voulais juste montré que c'était ici un choix vraiment regrettable de la part de Sun parcque la différence de perf est vraiment conséquente. Mais j'y vois surtout un problème au runtime pour l'introspection : on a des objects et plus aucune vérification de type, question robustesse boum.
[^] # 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é à 2.
Sauf que bien entendu toutes les exceptions "standards" sont "ignorées" par le compilo : "InvalidCastException", "NullPointerException", "OutOfMemoryException", etc. C'es les plus courantes et le compilo te diras jamais rien.
Si une librairie tierce change le prototype d'une méthode, je préfère être prévenu par mon compilo parce que la responsabilité, au final, elle est pour ma pomme et bien entendu je vais recompiler avec cette nouvelle bibliothèque!
oué mais si tu patches bêtement la lib sans recompiler ton appli ? Genre le client met à jour son OS et les libs qui vont bien, sans bien entendu recompiler les appli : une lib introduit une exception, boum le runtime Java ne voit pas la différence et casse tout. En C# t'as pas le problème grâce à la gestion du versionning qui détectera ce genre de différence.
Les maîtres mots dans mon secteur sont robustesse et maintenabilité.
Les miens aussi. J'ai essayé de montré assez clairement que C# introduisait pas mal de robustesse. Question maintenance je penses qu'on sera d'accord pour dire que .NET/Mono est bien mieux que Java pour ca : le versionning est un des plus complets en .NET/Mono alors qu'il est quasiment absent de Java.
Pour les perfs je voulais juste montré que c'était ici un choix vraiment regrettable de la part de Sun parcque la différence de perf est vraiment conséquente. Mais j'y vois surtout un problème au runtime pour l'introspection : on a des objects et plus aucune vérification de type, question robustesse boum.