38 votes

L'exception .NET interceptée est inopinément nulle

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.

13voto

Guido Kersten Points 11

Je suis juste tombé sur ce même problème. J'ai finalement découvert que j'ai attrapé différentes exceptions avec le même nom, comme vous l'avez fait:

 catch (ReflectionTypeLoadException ex)
{
    // ... 
}
catch (Exception ex)
{
    // ex is not null!
    // ...
}
 

Les deux sont nommés «ex». Changer l'un des deux noms a résolu ce problème pour moi, comme:

 catch (ReflectionTypeLoadException reflectionEx)
{
    // ... 
}
catch (Exception ex)
{
    // ex is null - that should not be possible!
    // ...
}
 

4voto

C.Evenhuis Points 10818

Vous devez vérifier si à un moment donné, l'IocContainer intercepte un Exception ex lance ex.InnerException sans vérifier s'il est nul.

C # accepte avec joie throw null et finit en catch (Exception) .

4voto

Alan Winslow Points 1

J'ai rencontré le même problème. L'exception est nulle lorsqu'ils sont affichés dans le débogueur, même si le bon type de l'exception - UpdateException - fut pris à partie. Je pouvais voir l'exception de l'ouverture de l'Exception Assistant.

Dès que j'ai désactivé "Effectuer Exécution Contrat de Vérification" pris exceptions où n'est plus nulle. Je suis activement à l'aide de contrats de code pour aller sur un an maintenant, et n'avait pas ce problème avant j'ai commencé à travailler avec EF 4.1 dans ce projet particulier, récemment, mais je ne sais pas si EF est une variable de contrôle en ce qui concerne la pris exceptions étant nulle.

0voto

Gangnus Points 7646

J'ai aussi la même situation. C'était un bogue du débogueur Eclipse. (Vraiment, cette situation ne peut être que le résultat d'un bug de débogueur.)

Le redémarrage d'Eclipse était suffisant - l'exception d'exécution devient normale, pas nulle. D'autres débogueurs pourraient ne pas être aussi gentils.

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