Nella pubblicazione precedente abbiamo visto come sia possibile ottenere le funzionalità dell'Health Check all'interno di un servizio gRPC. Oggi vedremo un altro middleware, molto comune nelle Web.API, utilizzato in un'applicazione gRPC, in grado di gestire gli errori in modo tale che la risposta alla chiamata rispetti un formato standardizzato e interpretabile.
Come per tutti i servizi l'implementazione deve partire dal file Program.cs, aggiungendo un servizio Interceptor all'interno delle opzioni di inizializzazione gRPC:
// Add services to the container. builder.Services.AddGrpc(options => { options.Interceptors.Add<LoggerInterceptor>(); });
Prima di analizzare il codice presente in LoggerInterceptor, modifichiamo il servizio GreeterService in modo tale che restituisca un errore, e creiamo un'applicazione console incaricata di effettuare le chiamate.
public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context) { throw new NotImplementedException("Errore"); }
Per configurare l'applicazione client dobbiamo ricordarci di importare i file .proto, come specificato nel nostro articolo su gRPC (https://www.aspitalia.com/articoli/asp.net-core5/grpc/usare-grpc-infrastruttura-nostri-servizi-web-p-3.aspx#title_1), successivamente possiamo procedere alla creazione di una nuova istanza GrpcChannel e chiamare l'endpoint modificato in precedenza.
var grpcEndpoint = "https://localhost:7030"; using var channel = GrpcChannel.ForAddress(grpcEndpoint); var c = new Greeter.GreeterClient(channel); try { var o = await c.SayHelloAsync(new HelloRequest { }); } catch (RpcException ex) { Console.WriteLine(ex.Message); }
Come si può notare, la classe dell'errore che riceveremo sarà di tipo RpcException. L'interceptor dovrà dunque intercettare qualsiasi tipo di eccezione che il servizio potrebbe emettere e sostituirla con un istanza di RpcException.
public class LoggerInterceptor : Interceptor { public override async Task<TResponse> UnaryServerHandler<TRequest, TResponse>( TRequest request, ServerCallContext context, UnaryServerMethod<TRequest, TResponse> continuation) { try { return await continuation(request, context); } catch (Exception e) { throw new RpcException(new Status(StatusCode.Cancelled, e.Message)); } } }
Dettaglio degno di nota è la posizione di e.Message: benchè RpcException abbia un costruttore che accetti, come secondo argomento, il messaggio di errore, il client potrà leggere il messaggio solo se inserito all'interno di Status, il quale si occuperà dunque, sia dello stato dell'eccezione che della causa che l'ha generata.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Ottimizzare la latenza in Blazor 8 tramite InteractiveAuto render mode
Utilizzare HiLo per ottimizzare le insert in un database con Entity Framework
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Specificare il versioning nel path degli URL in ASP.NET Web API
Come EF 8 ha ottimizzato le query che usano il metodo Contains
Utilizzare QuickGrid di Blazor con Entity Framework
Configurare policy CORS in Azure Container Apps
Utilizzare politiche di resiliency con Azure Container App
Filtrare e rimuovere gli elementi dalla cache del browser tramite le API JavaScript
Miglioramenti nelle performance di Angular 16
Utilizzare la libreria Benchmark.NET per misurare le performance
Accesso sicuro ai secrets attraverso i file in Azure Container Apps
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Utilizzare QuickGrid di Blazor con Entity Framework
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- ASP 3 per esempi
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0