Voir ci-dessous pour une explication de ce qui se passe
J'ai vraiment une drôle d'émission où l'exception interceptée est null.
Le code utilise la MEF et s'efforce de faire rapport à la composition des erreurs. L'utilisation du débogueur je peux voir l'exception levée (un InvalidOperationException
), mais lorsqu'il est attrapé par le dernier bloc catch dans le code ci-dessous l' ex
variable est null. Cela est vrai tant dans le débogueur et lors de l'exécution du code normalement.
static T ResolveWithErrorHandling<T>() where T : class
{
try
{
IocContainer.Compose(Settings.Default.IocConfiguration);
return IocContainer.Resolve<T>();
}
catch (ReflectionTypeLoadException ex)
{
// ... special error reporting for ReflectionTypeLoadException
}
catch (Exception ex)
{
// ex is null - that should not be possible!
// ... general error reporting for other exception types
}
return null;
}
Le code je l'ai remplacé avec des commentaires est vraiment simple code pour mettre en forme le message d'erreur. Rien d'étrange là.
J'ai essayé de modifier le code de découvrir quel effet cela pourrait avoir:
- Si je supprime le premier bloc catch (
ReflectionTypeLoadException
) à l'exception interceptée dans le dernier bloc catch n'est plus nulle. - Si je prends un autre type d'exception dans le premier bloc catch l'exception pêché dans le dernier bloc catch n'est plus nulle.
- Si j'ajoute un bloc catch pour
InvalidOperationException
comme le premier bloc catch l'exception interceptée dans ce bloc n'est pas nulle. - Si j'ajoute un bloc catch pour
InvalidOperationException
entre les deux blocs catch l'exception pris dans ce bloc est null.
Le projet utilise des Contrats de Code et le code généré par le compilateur est en post-traitement afin de vérifier les contrats. Malheureusement, je havn'pas trouvé un moyen pour se débarrasser de ce à des fins de test sans procéder à une intervention chirurgicale majeure sur le projet.
Ma solution actuelle est de ne pas attraper ReflectionTypeLoadException
et au lieu de branche sur le type d' ex
dans le gestionnaire d'exception générale.
Ce qui pourrait être l'explication de cet "impossible" comportement? Ce qui est en haut avec ReflectionTypeLoadException
bloc catch?
Embarrassant, l'exception n'est pas nul et il ne peut pas être null pour le C# standard 15.9.5.
Cependant, l'utilisation de Contrats de Code dans un projet peut gâcher l'affichage des variables locales dans le débogueur. Dans mon cas, l' ex
variable est affichée nulle même si elle ne l'est pas. La nature de la malheureuse erreur de déclaration tenant lieu juste avant l'arrêt de l'application, j'ai cru le rapport d'erreurs à ne pas être appelé comme un résultat de l' ex
nul et ex.Message
jetant un NullReferenceException
à l'intérieur de mon bloc catch. L'utilisation du débogueur j'ai pu "vérifier" que ex
a été nulle, sauf qu'elle n'était pas nulle.
Ma confusion est aggravée par le fait qu'un bloc catch pour ReflectionTypeLoadException
semble affecter le débogueur problème d'affichage.
Merci à tous ceux qui ont répondu.