Essayez Attraper - pas attraper

Question

Voici mon problème. J'ai un service web de middleware utilisé par plusieurs clients web. Le service Web est un service d'encapsulation qui appelle les services Web de plusieurs fournisseurs. L'appel au service Web du fournisseur est enveloppé dans une TryCatch, mais les exceptions générées ne sont pas interceptées par mon service Web, elles sont interceptées dans les applications client.

Ai-je raté quelque chose? Est-ce lié à ce posting?

Voici un extrait de code simplifié:

Dim VendorWebservice as New VendorWebservice 
    Dim VendorResponse As VendorResponse = Nothing 
    Dim ClientResponse as New CustomClientResponse 
    Try 
     VendorResponse = VendorWebservice.VendorWebMethod 
    Catch ex As Exception 
     ClientResponse.ErrorMessage = ex.Message 
     ClientResponse.Status = "VendorError" 
     Return ClientResponse 
    End Try 

EDIT

Pour élargir certains détails ... Le code est exécuté avec succès 99% du temps. À l'occasion rare qu'il y a un problème avec le site Web du fournisseur est lorsque ce problème se produit. J'ai eu VS ouvert à la fois pour l'un des clients Web et le service Web et peut passer par le code du client vers le WS et retour. Quand je peux reproduire le problème, j'ai passé le code client à l'endroit où il appelle notre service Web, puis je passe au code WS et j'exécute jusqu'à ce qu'il appelle le code du fournisseur et à ce moment, il retourne au code client, sans frapper le bloc Catch ou tout autre code après.

Espérons que ça aide.

EDIT

Certaines des réponses affichées ont fourni des avenues à la recherche, la plupart notibly qu'il ya des exceptions qui peuvent être créées qui ne sont pas dérivés de System.Exception. (Qui le savait?) Mais j'ai également découvert qu'à partir de .NET 2.0 et plus tard, ces exceptions non-System.Exception sont enveloppées par .NET dans une exception System.Exception. Donc, en théorie, cela devrait exclure les non-System.Exceptions. En outre, d'après mes lectures, lorsque j'appelle un service Web (comme mon service Web le fait), en théorie, seuls deux types d'exceptions devraient être réellement visibles, System.Net.WebException et System.Web.Services.Protocols.SoapException. , les deux dérivent de System.Exception. Je ne sais pas si c'est vraiment vrai s'il n'y a que 2 types d'exceptions possibles lors de l'appel d'un service web, mais je vais le jeter là. :)

Toujours à la recherche d'une réponse ...

EDIT

Reproduire la condition d'erreur est avérée être difficile à atteindre. Chaque scénario que j'ai lancé sur le code a répondu comme prévu, l'erreur étant interceptée dans le bloc Catch. Alors qu'en théorie .NET est supposé encapsuler des exceptions qui ne dérivent pas de System.Exception, la seule réponse logique semble être en accord avec la réponse de Joe que l'exception que nous avons expérimentée NE dérive PAS de System.Exception et est donc traitée comme non gérée. exception.

Answer 1

Les exceptions générées sont-elles dérivées de Exception? (Est-ce que 'Exception' se réfère certainement à 'System.Exception')

Answer 2

Etes-vous sûr que l'exception se produise dans le try/catch?

essayez de déplacer le « comme neuf » à l'intérieur du try/catch trop

Answer 3

Il est commun pour les services Web de ne pas jeter des exceptions, mais au lieu de retourner une sorte d'objet d'erreur ou un message d'erreur ou d'état. Si vous placez un point d'arrêt après avoir appelé VendorResponse, vous pouvez examiner ce qui a été renvoyé et voir s'il existe des propriétés "error" ou "status". Si c'est le cas, vous pouvez tester le contenu de ceux dans votre code, puis lancer une exception ou gérer autrement la situation.

Answer 4

Personnellement, je trouve qu'il est difficile de croire qu'une erreur se produit dans ce code et ne pas être pris dans le catch try. Peut-être mettre un enfin et voir si cela s'exécute. D'abord, vous avez besoin d'un moyen décent pour recréer votre erreur. La prochaine chose que je ferais est de tenter de comprendre exactement où dans le code l'erreur est levée. Ce que je ferais serait de mettre temporairement des instructions de journalisation (Debug.Output peut-être) après chaque ligne de code afin que vous puissiez être sûr des lignes réellement exécutées. Lorsque votre erreur se produit, vous serez en mesure de regarder la sortie de ces journaux pour voir au moins où l'erreur se produit. Maintenant que vous le savez, cela peut vous donner une meilleure idée de ce qui se passe. Si toutes les instructions de journalisation apparaissent, alors vous savez que l'erreur ne se produit pas dans ce bloc de code. Ma première estimation est que c'est ce qui se passe.

Puisque rien ne tombe dans la prise, vous devez éliminer tout ce qui pourrait se passer. Si possible, mettez ce morceau de code dans une petite application de harnais de test pour voir si elle fonctionne correctement.

J'espère que cela vous aidera.

Answer 5

J'ai déjà vu cette même erreur dans du code d'un travail précédent. Dans notre cas, l'erreur qui était en train d'être lancée ne dérive PAS de System.Exception. Une fois que nous avons su cela, c'était assez facile de le gérer correctement.