Hallo zusammen
Ich würde gerne eine RestApi nutzen. Dazu habe ich eine Client- Klasse erstellt und diese generisch gestaltet. Nun würde ich gern über "Try,Catch" etwaige Fehler abfangen. Allerdings bin ich mir nicht sicher wie ich mit den Fehlern umgehen soll. Wie wird hier normalerweise vorgegangen? Ich hatte den Aufbau so gewählt um Aufrufe an den Client zu vereinfachen und um den Client in den Tests Mocken zu können. Des weitern würde ich gern die Fehler in dieser Klasse abfangen, um in den Repositorys lediglich mit den empfangen bzw. nicht empfangenen Daten arbeiten zu können und dort weitestgehend ohne Exceptions-Handling aus zu kommen.
public class ApiClientService : IHttpClientService<string>
{
private HttpClient _httpClient;
public ApiClientService(HttpClient httpClient)
{
_httpClient = httpClient;
}
public ApiClientService()
{
_httpClient=new HttpClient();
}
public async Task<string> GetData(HttpRequestMessage httpRequestMessage, CancellationToken _Token)
{
try
{
using (var response = await _httpClient.SendAsync(httpRequestMessage, _Token))
{
//Logger implementeieren => success response
response.EnsureSuccessStatusCode();
var body = await response.Content.ReadAsStringAsync();
//Pass not String
if (body.GetType() != typeof(string))
{
//Logger implementieren
throw new Exception("return is no string");
}
return body;
}
}
catch (Exception exception)
{
}
}
}
Was man generell nie macht, ist sowas:
throw new Exception("return is no string");
Exception Handling - C# Programming Guide
Wie wird hier normalerweise vorgegangen?
Das kommt drauf an. Du sprichst von ApiClientService
, wofür ich nie den HttpClient verwende, sondern die Abstraktion refit, die hier einem viel abnimmt.
Wie Du in der Dokumentation von HttpClient sicherlich gelesen hast ist zudem die Nutzung von EnsureSuccessStatusCode
dafür gedacht, dass Dich das Behandeln von Fehlern nicht interessiert: Du willst den Erfolg, nicht das Scheitern.
Willst Du Fehler des HttpClient selbst handlen, was okay ist, dann darfst auch kein EnsureSuccessStatusCode
verwenden.
Dann geht man auf die Status Codes und implementiert pro Status Code einen Return.
PS: Wie Du im Guide Exception Handling - C# Programming Guide nachlesen kannst sind Exceptions eigentlich nicht für die Steuerung von Code gedacht, sondern von Behandeln von Fehlern.
Eine saubere Implementierung hier wäre ein entsprechend eigener Return Type, über den man den Return bei Success bekommt und den Fehler bei Fail - aber keine hunderte von Exceptions pro Status Code oder nur weil der Body leer is.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code