Bonjour,

Je développe une petite application pour faire du monitoring de serveur que je contacte par API.

Je simule un serveur arrêté.

string result = client.GetAsync("http://" + config.pasoe[CbPasoe.SelectedIndex].adresse + "/oemanager/applications").Result.Content.ReadAsStringAsync().Result;

Ce code doit me généré une exception de type HttpRequestException.

cependant, je récupère une exception de type AggregateException.

Comment je peux faire pour modifié ça ?

L'exception généré contient bien une exception de type HttpRequestException dans l'exception AggregateExeption

intercepte aussi l'AggregateException et vérifie qu'elle contient bien une HttpRequestException cf la doc https://docs.microsoft.com/fr-fr/dotnet/api/system.aggregateexception?view=net-5.0 

l'AggregateException se produit parce que (sauf erreur de ma part) l'instruction ne peut pas aller au bout, l'erreur se produit dans une des fonctions chainées.

Bonjour,

merci pour ta réponse, c'est ce que j'ai fait.

Cependant, même en découpant l'instruction au minimum (seulement le getAsync) j'ai quand même une aggregateException.

Je sais pas si c'est le passage à la dernière version du C# qui fait ça, mais il y a 1/2 ans j'avais déja utilisé cette instruction et je récupérerais bien l'exception directement.

Et je n'arrive pas à trouver dans la doc l'explication du pourquoi l'exception est en encapsulée dans une aggregate.

Dans mon exemple seulement cette exception peut arriver et c'est bien la seule contenu dans l'aggregate.

Il n'y a pas la classe et la méthode qui encapsule l’exception Http... dans l'exception Agg... ?

C'est plus dans la documentation de cette méthode "interceptrice/englobante" qu'il faut chercher.

J'ai bien la bonne erreur contenu dans l'exception Aggregate.

Mais je m'attendais a recevoir une exception de type Http... directement.

Est-ce un changement et comment "désactiver" l'agrégation des exceptions ? (si c'est possible bien sur) 

Le framework .NET est OpenSource, vous pouvez facilement déterminer où et pourquoi il y a eu cette "encapsulation".

Les callstack sauvegardées avec les exceptions devraient montrer facilement où s'est produit cette "encapsulation".

Merci pour le lien.

J'avais déja utilisé HttpClient mais c'était en .Net Framework 4.X, d'où le fait que je n'avais pas vu cette exception.

Il faudrait que je m'en souvienne si un jour mon code précédent fonctionne toujours quand Microsoft supprimera .Net Framework de windows