Tryfoo devrait-il jamais jeter une exception?

Cela dépend de ce que la méthode tente de faire.

Si la méthode par exemple lit une valeur de chaîne à partir d'un lecteur de données et tente de l'analyser dans un entier, il ne doit pas lancer une exception si l'analyse échoue, mais elle devrait lancer une exception si le lecteur de données ne peut pas lire à partir de la base de données ou si la valeur que vous lisez n'est pas une chaîne du tout.

La méthode devrait suivre le principe général pour accroître les exceptions que vous ne devez attraper que ce que vous savez comment gérer. Si une exception complètement différente se produit, vous devez laisser cette bulle jusqu'à un autre code qui sait comment le gérer.

Mettez un autre moyen, si vous écrivez tryfoo, garantiriez-vous que des exceptions ne peuvent pas échapper, par l'écrire comme ça?

Non, je n'invaluerais pas d'exceptions dans ma méthode tryfoo. Foo dépend de Tryfoo, pas l'inverse. Puisque vous avez mentionné le dictionnaire générique, qui a une méthode getvalue et une méthode trygetvalue, j'écrirais mes méthodes de dictionnaire comme suit: xxx

donc, getvalue dépend de la trygetvalue et jette un Exception si trygetvalue retourne faux. C'est bien mieux que d'appeler GetValue à partir de trygetvalue et d'avaler l'exception résultante.

Mais si tryfoo permet de s'échapper à quelques exceptions, alors ce qu'elle dit vraiment est: "Je ne jetterai aucune exception que je sais que je sais comment gérer", puis toute l'idée du contrat "Je ne vais pas lancer d'exceptions" est jeté de la fenêtre.

Je pense que vous l'avez dit ici ici :)

tryxxx ne devrait garantir que s'il ne lancera pas d'exceptions, il sait manipuler. Si cela ne sait pas comment gérer une exception donnée, pourquoi devrait-il l'attraper? La même chose vaut pour vous - si vous ne savez pas quoi faire, pourquoi l'attraperiez-vous? BadallOcExceptions par exemple, bien, (USsudialement) pas beaucoup à faire à propos de ceux-ci, sauf pour les attraper dans votre mode principal Essayer / Catch, montrez un message d'erreur et essayez de fermer l'application gracieusement ..

Les deux autres questions de StackoverFlow que vous avez liées pour sembler être des bugs authentiques. Celui où uri.trycreate jette une exception uformatexception pour L'exemple est définitivement une pause dans le contrat, car la documentation MSDN pour cette méthode indique explicitement:

ne jette pas une exception si l'URI ne peut pas être créée.

L'autre, TryDequeue, je ne trouve aucune documentation pour, mais cela semble aussi être un bug. Si les méthodes étaient appelées tryxxx mais la documentation indiquait explicitement qu'ils pouvaient lancer des exceptions, vous pourriez avoir un point.

généralement, il y aura deux versions de ce type de méthode, qui jette des exceptions et une seule. Par exemple, int32.parse et int32.trypsarse . Le point de la méthode tryxxx n'est pas de masquer exceptions. C'est pour des situations où l'échec n'est pas en réalité une condition exceptionnelle. Par exemple, si vous lisez dans un numéro de la console et que vous souhaitez continuer à essayer jusqu'à ce qu'un nombre correct soit en entrée, vous ne voulez pas continuer à attraper des exceptions. De même, si vous souhaitez obtenir une valeur d'un dictionnaire, mais c'est un cas parfaitement normal qu'il pourrait n'existerait pas, vous utiliseriez trygetvalue .

résumé : tryxxx ne doit pas lancer d'exceptions et il n'est pas conçu pour cacher des exceptions non plus. C'est pour les cas où il est normal et non exceptionnel d'échouer, et vous souhaitez détecter ce cas facilement sans les frais généraux et l'effort d'attraper une exception. Habituellement, une méthode non tryxxx, qui fournit des exceptions, est également fournie, car les cas où il est exceptionnel.