Comment l'exception interceptée peut-elle être nulle (pas NullReferenceException)?

J'ai rencontré un petit problème plutôt étrange.Comment l'exception interceptée peut-elle être nulle (pas NullReferenceException)?

Dans le code suivant je ne peux pas comprendre comment e peut être null;

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    //Here e is null 
}

Pour autant que je sache, throw null sera converti en throw new NullReferenceException().

Le problème semble être lié au multithreading, car la suppression d'un autre thread semble également le réparer. Ou au moins, je n'ai vu cela que lorsque le code ci-dessus est exécuté dans un nouveau thread. L'ensemble du programme utilise beaucoup de threads et est un peu complexe.

De toute façon ma question est, comment peut e être nul? - J'espère que la réponse à cela peut aider à trouver la source de ce problème.

Modifier Je l'ai découvert depuis qu'il a provoqué une NullReferenceException dans la déclaration de capture, et en utilisant le débogueur, je vois la même chose.

Edit 2 Ouvrez VisualStudio le lendemain essayé à nouveau, aucun changement de code et maintenant le même slogan est « appelé » mais cette fois-e est pas nul. Il semble que c'était un pépin VS.

Source

2009-12-03 Jacob Poul Richardt

Il semble que vous ayez déjà mis le doigt sur le problème. Vous devez obtenir le foulage redressé. –

Comment déterminez-vous que e est en fait nul? J'ai essayé quelques exemples et lu la spécification CLI sur les exceptions et cela ne semble pas permettre qu'une valeur d'exception soit nulle. De plus, s'il était nul, il n'aurait pas de type et ne serait donc pas capable de répondre aux critères de filtrage pour être de type exception.

Utilisez-vous le débogueur pour vérifier cette valeur? Si c'est le cas, essayez de le remplacer par un assertion en ligne.

Source

2009-12-03 17:35:10 JaredPar

Je vais mettre à jour la question avec ça. Mais cela a attiré mon attention car une exception NullReferenceException a été lancée à partir de l'instruction catch. Et en utilisant le débogueur, je vois la même chose. –

@Lillemanden, cela ne prouve pas que c'est nul. Seul un Debug.Assert (e! = Null, "C'est définitivement nul") ou une vérification similaire le fera. – JaredPar

Le débogueur ment parfois. Je me souviens qu'il y a quelque chose de divertissant avec les constantes et le débogueur où ils semblent être vides ou nuls quand ils ne sont pas dans la réalité. – Quibblesome

Il est possible que l'exception lancée ne soit pas compatible CLS, ce qui ne devrait pas être captable par un Try/Catch avec un filtre.

Vous ne devriez pouvoir attraper un CLS conforme à une try {} catch {} sans exception "argument"

Source

2009-12-03 18:07:07

Je suis à peu près sûr que tout le code est conforme CLS. Bien que pas 100%. Mais je n'ai jamais eu ce problème auparavant. Et il y a beaucoup d'autres déclarations de catch, dont la plupart auraient dû être testées par des tests unitaires. –

Êtes-vous positive que vous étiez hors de l'exception ligne e?

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    int i = 0; // breakpoint here 
}

Je demande seulement parce que je ne l'ai jamais, jamais vu ce genre de comportement et je sais que si vous Exception e point d'arrêt, e semble être nulle. Sur la ligne suivante, il devient non nul.

Source

2009-12-03 18:09:17 Quibblesome

Oui, je suis positif. L'utilisation de e dans l'instruction catch a provoqué une exception NullReferenceException. –

J'ai aussi la même situation. Il s'est avéré être un bug de débogueur Eclipse. Le redémarrage d'Eclipse est suffisant - l'exception d'exécution devient normale, et non nulle.

Source

2012-01-18 09:23:03 Gangnus

Comment l'exception interceptée peut-elle être nulle (pas NullReferenceException)?

Répondre

Questions connexes