Éviter les messages d'exception de première chance lorsque l'exception est gérée en toute sécurité

StackOverflow https://stackoverflow.com/questions/58380

  •  09-06-2019
  •  | 
  •  

Question

Le bit de code suivant intercepte l'exception EOS

using (var reader = new BinaryReader(httpRequestBodyStream)) {

    try {
        while (true) {
            bodyByteList.Add(reader.ReadByte());
        }
    } catch (EndOfStreamException) { }
}

Alors pourquoi est-ce que je reçois toujours des exceptions de première chance dans ma console ?

Une exception de première chance de type « System.IO.EndOfStreamException » s'est produite dans mscorlib.dll

Existe-t-il un moyen de masquer ces messages d'exception de première chance ?

Était-ce utile?

La solution

Le but des exceptions de "première chance" est que vous les voyez avant le gestionnaire afin que vous puissiez vous y arrêter pendant le débogage au moment du lancement.Une exception de « seconde chance » est une exception qui n'a pas de gestionnaire approprié.Parfois, vous souhaitez détecter les exceptions « à la première chance », car il est important de voir ce qui se passe lorsqu'elles sont émises, même si quelqu'un les détecte.

Il n'y a pas de quoi s'inquiéter.C'est un comportement normal.

Autres conseils

Pour éviter de voir les messages, faites un clic droit sur la fenêtre de sortie et décochez « Messages d'exception ».

Cependant, les voir se produire peut être agréable si vous souhaitez savoir quand des exceptions sont levées sans définir de points d'arrêt ni reconfigurer le débogueur.

1) Dans Visual Studio, vous pouvez modifier les paramètres relatifs à la manière dont le débogueur gère (interrompt) les exceptions.

Accédez à Débogage > Exceptions.(Notez que cela peut ne pas figurer dans votre menu en fonction de votre paramètre d'environnement Visual Studio.Sinon, ajoutez-le simplement à votre menu en utilisant le menu Personnaliser.)

Là, une boîte de dialogue d'exceptions vous est présentée et indique quand les rompre.

Dans la ligne "Exceptions Common Language Runtime", vous pouvez désélectionner la levée (ce qui devrait alors cesser de vous déranger avec les exceptions de première chance) et vous pouvez également désélectionner Non géré par l'utilisateur (ce que je ne recommanderais pas) si vous le souhaitez.

2) Le message que vous recevez ne doit pas figurer dans la console, mais doit apparaître dans la fenêtre « Sortie » de Visual Studio.Si tel est le cas, je n'ai pas trouvé de possibilité de supprimer cela, mais cela n'apparaît pas si vous exécutez l'application sans Visual Studio.

J'espère que cela pourra aider.

Contrairement à Java, les exceptions .NET sont assez coûteuses en termes de puissance de traitement, et les exceptions traitées doivent être évitées dans le cadre d'une exécution normale et réussie.

Non seulement vous éviterez l'encombrement dans la fenêtre de la console, mais vos performances s'amélioreront et cela rendra les compteurs de performances tels que les exceptions .NET CLR plus significatifs.

Dans cet exemple, vous utiliseriez

while (reader.PeekChar() != -1)
{
    bodyByteList.Add(reader.ReadByte());
}

J'ai eu ce problème et je n'arrivais pas à comprendre où l'exception avait été levée.Ma solution consistait donc à permettre à Visual Studio d'arrêter de s'exécuter sur ce type d'exception.

  1. Accédez à "Débogage/Exceptions"
  2. Développez l'arborescence « Exceptions du Common Language Runtime ».
  3. Développez la branche "Système".
  4. Faites défiler jusqu'à l'endroit où se trouve "NullReferenceException", et cochez la case "Throw" et décochez la "mange de l'utilisateur".
  5. Déboguez votre projet.

Si vous souhaitez plus de contrôle sur ces messages, vous pouvez ajouter un gestionnaire :

Friend Sub AddTheHandler()
AddHandler AppDomain.CurrentDomain.FirstChanceException, AddressOf FirstChanceExceptionHandler
End Sub

<Conditional("DEBUG")>
Friend Sub FirstChanceExceptionHandler( source As Object,  e As Runtime.ExceptionServices.FirstChanceExceptionEventArgs)
' Process first chance exception

End Sub

Cela vous permet de les faire taire comme mentionné dans d'autres commentaires, tout en garantissant que vous pouvez en être conscient.Je trouve qu'il est bon de voir combien j'en lance réellement si j'enregistre un message et un horodatage dans un fichier texte.

En fait, si vous avez de nombreuses exceptions par seconde, vous obtiendrez de meilleures performances en vérifiant reader.EndOfStream-value.L'impression de ces messages d'exception est incroyablement lente et les cacher dans Visual Studio n'accélérera rien.

en VB.NET :

<DebuggerHidden()> _
Public Function Write(ByVal Text As String) As Boolean
   ...

Je pense que le flux lève cette exception, donc votre essai est limité à la capture.

Ajoutez quelques combos try catch supplémentaires autour des différentes portées jusqu'à ce que vous l'attrapiez là où il est réellement lancé, mais cela semble se produire soit à l'extérieur de votre utilisation, car l'objet stream n'est pas créé dans la portée de l'utilisation.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top