Remarque : il ne s'agit pas une duplication de la question de Jeff .
Cette question demandait "Est-ce qu'un équivalent ?" Je sais qu'il n'y en a pas, et je veux savoir pourquoi !
Si je vous demande cela, c'est que je viens tout juste de comprendre l'importance de cette question et que la conclusion me semble très étrange.
Le bloc de gestion des exceptions de la bibliothèque d'entreprise de Microsoft nous conseille d'utiliser ce modèle :
catch (Exception x)
{
if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
throw;
// recover from x somehow
}La politique est définie dans un fichier XML, ce qui signifie que si un client a un problème, nous pouvons modifier la politique pour l'aider à localiser (ou peut-être à masquer) le problème afin de lui donner une solution rapide jusqu'à ce que nous le traitions correctement - ce qui peut impliquer de se disputer avec des tiers, pour savoir à qui la faute.
Il s'agit essentiellement d'une reconnaissance du simple fait que, dans les applications réelles, le nombre de types d'exceptions et leur statut de "récupérabilité" sont pratiquement impossibles à gérer sans un tel dispositif.
Pendant ce temps, l'équipe CLR de MS dit que ce n'est pas une option, et il s'avère que ces gars-là savent de quoi ils parlent ! Le problème est que juste avant que le catch le bloc s'exécute, tout finally imbriqués dans les blocs try sera exécuté. Ainsi, ces finally Les blocs peuvent effectuer l'une des actions suivantes :
- Modifier de manière inoffensive l'état du programme (ouf, chanceux).
- Jeter quelque chose d'important dans les données du client, parce que l'état du programme est foutu à un degré inconnu.
- Déguiser ou détruire des preuves importantes dont nous avons besoin pour diagnostiquer un problème - surtout si nous parlons d'appels au code natif.
- Lancer un autre exception, ajoutant à la confusion et à la misère générale.
Notez que le using et les destructeurs C++/CLI sont construits à partir de try / finally donc ils sont aussi concernés.
Il est donc clair que le catch / throw Le modèle de filtrage des exceptions n'est pas bon. Ce dont nous avons besoin, c'est d'un moyen de filtrer les exceptions, via une politique, sans les attraper et donc sans déclencher l'exécution de la commande finally à moins que nous ne trouvions une politique qui nous dise que l'exception est sans danger pour la récupération.
L'équipe CLR a récemment publié un blog à ce sujet :
- Attraper, relancer et filtrer - Pourquoi s'y intéresser ?
- Pourquoi catch(Exception)/empty catch est mauvais
Le résultat est que nous devons écrire une fonction d'aide en VB.NET pour nous permettre d'accéder à cette capacité vitale depuis C#. Le gros indice qu'il y a un problème est qu'il y a du code dans la BCL qui fait cela. De nombreuses personnes ont écrit des articles sur la façon de le faire, mais elles ne mentionnent que rarement, voire jamais, la chose suivante try / finally blocs, ce qui est le tueur.
Ce que je voudrais savoir, c'est :
- Y a-t-il des déclarations publiques ou des courriels directs que les gens ont reçus de l'équipe C# à ce sujet ?
- Existe-t-il des suggestions de Microsoft Connect existantes qui demandent cela ? J'ai entendu des rumeurs à ce sujet, mais aucun des mots-clés n'a donné de résultat.
Mise à jour : Comme indiqué ci-dessus, j'ai déjà effectué des recherches sur Microsoft Connect sans rien trouver. J'ai également (sans surprise) fait des recherches sur Google. Je n'ai trouvé que des personnes en expliquant pourquoi ils ont besoin de cette fonctionnalité ou en soulignant la ses avantages en VB.NET ou en espérant futilement que ce sera ajouté dans une future version de C# o contourner le problème Et beaucoup de conseils trompeurs . Mais aucune déclaration sur la raison de son omission dans toutes les versions actuelles de C#. Et la raison pour laquelle je pose des questions sur les problèmes de connexion existants est que (a) je ne crée pas un doublon inutile et (b) je peux dire aux personnes intéressées si je dois en créer un.
Mise à jour 2 : Trouvé un ancien billet de blog intéressant d'Eric Gunnerson anciennement de l'équipe C# :
"Oui, être capable de mettre une condition sur une capture est un peu plus pratique que d'avoir à écrire le test vous-même, mais cela ne vous permet pas vraiment de faire quelque chose de nouveau".
C'était la même hypothèse que j'avais jusqu'à ce qu'on me l'explique correctement !
