22 votes

Pourquoi n'était-ce pas la Java "lance" de l'alinéa (dans la déclaration de la méthode) inclus dans C#?

Pourquoi n'était-ce pas la Java "lance" de l'alinéa (dans la déclaration de la méthode) inclus dans C#?

30voto

Patrik Hägne Points 7735

Anders Hejlsberg (le plomb C# architecte) explique dans cette interview:

http://www.artima.com/intv/handcuffs.html

20voto

Jon Skeet Points 692016

(En plus de Patrik est un peu la réponse définitive.)

Checked exceptions en Java sont une question très controversée. J'ai utilisé pour l'aimer, et a manqué beaucoup lors de l'écriture de C#. Il me sentais comme conduire sans ceinture de sécurité. Maintenant, ils me gênent... parce que d'une bonne idée en théorie, ils ont certainement m'a causé beaucoup de chagrin, mais sans fournir beaucoup d'avantages tangibles. Je ne me souviens jamais de la rencontre d'un bug dans le code C# qui a vérifié les exceptions m'aurait évité. Cela ne veut pas dire qu'il ne peut pas se produire, mais il n'est pas arrivé à moi.

L'ennuyeux, c'est que, à certains égards, il se sent encore comme C# est trop laxiste - mais que Java approche n'est pas tout à fait le droit. C'est comme il y a une meilleure solution en attente d'être découvert, et Java tentative a été une bonne expérience, mais il n'a pas assez de travail.

3voto

kgiannakakis Points 62727

La raison principale est que C# créateurs ont décidé de ne pas utiliser "checked exceptions". Cela signifie que le développeur n'a pas à entourer l'exception de jeter de la clause à l'intérieur d'un bloc try-catch. Il a été considéré que ce n'est seulement utile pour les petites applications à grande échelle et n'ont pas un réel avantage pour les plus gros projets. En outre vérifié exceptions ont été effectivement utilisées à mauvais escient par les développeurs, qui utilisent constamment vide blocs catch. Depuis il n'y a pas vérifié les exceptions, il n'y a aucune raison pour qu'une méthode de déclarer, qui à l'exception, peut être jeté.

L'utilisation ou non de "checked exceptions" est un sujet controversé, mais la plupart semblent d'accord pour dire qu'il n'est pas nécessaire pour eux. Printemps, qui est un éminent cadre en Java, tourne vérifié les exceptions en exécution de celles.

3voto

Scott Wisniewski Points 14420

Je pense que checked exceptions, comme pour le langage, expose certaines différences culturelles entre Microsoft et Sun.

Pour la plupart, Microsoft est une entreprise cliente. La plupart des logiciels qu'ils font, et ce que leur pile de développement cible, est un logiciel client.

Oui, oui, je sais que Microsoft rend le logiciel serveur. Toutefois, le Bureau et les Fenêtres sont bien plus grands en termes de revenus que l'exploitation Windows Server et Exchange sont.

Je pense qu'il est juste de dire que la plupart des logiciels écrits dans .NET, (et encore plus avec VB 6) est un logiciel client. Bien sûr, une grande partie de cela est un Logiciel Web qui s'exécute sur un Serveur Web, mais c'est vraiment ... "clienty type web apps". Je dirais que la plupart des applications web sont de plus comme "Word" puis ils sont comme Échange.

Et oui, je sais qu'il y a de la WCF et des services SOAP et des choses comme ça, mais ceux qui sont habituellement seulement "middle ware" pour "clienty" genre de chose.

Le soleil, d'autre part, est principalement un serveur de l'entreprise. Leur logiciel n'est pas exactement le plus grand quand il s'agit de l'interface utilisateur (ce n'est pas une légère sur Unix... juste Solaris.. Mac OS X est basé sur unix et il a une phénoménale de l'interface utilisateur, la différence entre les deux est que le Soleil vraiment ne se soucient pas autant de l'INTERFACE utilisateur que fait Apple ). Ils vendent même des CLIENTS légers, qui tentent de repousser tout sur le serveur.

Alors... en tout cas... Microsoft est principalement un client de l'entreprise, et le Soleil est principalement un serveur de l'entreprise.

Lorsque vous écrivez le logiciel serveur, la fiabilité est une grande chose. Il est énorme. Si un e-mail serveur tombe en panne, les gens ne peuvent pas recevoir des e-mails, et les entreprises s'enraye. Donc, faire en sorte que le serveur peut gérer intelligemment la plupart des erreurs qui peuvent arriver, c'est une grande partie de la vente d'un serveur de messagerie.

Avec un logiciel client. la fiabilité EST importante, mais pas loin d'être AUSSI importante qu'elle l'est avec le logiciel serveur. Aussi longtemps que la plupart de la ligne principale de scénarios de travail, les gens sont heureux. Dans de nombreux cas, à la folie bord scénarios peuvent être ignorés ou traités d'une manière générique.

Une clé pour être en super fiable est de s'assurer que vous manipulez tous les cas qui peuvent se produire. Qu'advient-il si vous ne pouvez pas ouvrir le fichier de base de données, car il est verrouillé par un autre processus, ou nous n'avons pas l'autorisation de le lire? Que faire si nous venons à manquer de mémoire ou d'espace disque? Ce qui se passe si une panne de courant lors de l'exécution de cette procédure?

Avec de très hautes exigences en matière de fiabilité, après avoir vérifié les exceptions PEUVENT être utiles. Si il y a un scénario, vous n'avez pas anticiper, et il est important pour votre entreprise que vous avez tout prévoir, et d'avoir ensuite le compilateur vous dire ... "hey, vous n'avez pas gérer la RocketFuelExhaustedException" serait utile.

Donc, je pense que checked exceptions souches de Soleil du point de vue d'un fournisseur de serveur.

Pour Microsoft, en tant que client de la société de vente des outils de développement pour les développeurs de logiciels clients, vérifié les exceptions sont bien sûr terriblement irritant des choses qui sont juste dans la voie du vrai travail se fait.

C'est mon de 0,02 $tout de même...

0voto

Thomas Danecker Points 3127

Les Exceptions sont apparemment "exceptionnelle" des événements. Dans .net paradigmes, les exceptions ne devraient jamais se produire (c'est pourquoi vous avez des méthodes comme l' TryParse, ...), il n'a guère de sens d'être forcé de traiter des événements qui ne devraient pas se produire de toute façon.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X