ASP.NET Core Exception Handling Tutorial | .NET 8

[@VinodKumarGowda]

As usual very neat and useful.

[@juliocasal]

Glad you think so!

[@FB-eb6tx]

Very nice! Thanks Julio! This kind of videos are awesome!

[@juliocasal]

Glad you liked it!

[@singhtech4938]

Hi @juli , could you please make a video to how we can save these logs into database or in third party logging system like loggly, or scaler ?

[@juliocasal]

I cover that here: dotnetmicroservices.com

[@bloopers2967]

Great and detailed information. Thanks

[@juliocasal]

Glad it was helpful!

[@dorlugasigal]

I wonder regarding the validationException you had there, I assume fluentValidation Isnt it having some performance hit throwing a validation exception rather then just getting the validation result object and look at the IsValid property? Its true that its more clean without the if statement, but is it more performant to enter a try catch statement for every place you have validation?

[@juliocasal]

Which validation exception? Not using FluentValidation here.

[@2u1u]

@julio prior to dotnet 8, would we just add a middleware try/catch and handle it that way?

[@juliocasal]

Prior to .NET 8, you can do this: kzbin.info/www/bejne/pKrGenxjeMqWb6s

[@coding-in]

Hi Julio, thank you for this video especially for writing tuple i just found out in that way. Anyway, how to get the request body? It can help us to identify or reproduce the error.

[@juliocasal]

Glad to help. Have not tried getting the request body.

[@coding-in]

@@juliocasal iv tried this: string requestBody = await new StreamReader(httpContext.Request.Body).ReadToEndAsync(); httpContext.Request.Body.Position = 0; but always return null or empty.

[@coding-in]

@@juliocasal finally i found the solotution to get request body using: using (var reader = new StreamReader(httpContext.Request.Body)) { // Reset the stream position to the beginning after enabling buffering httpContext.Request.Body.Seek(0, SeekOrigin.Begin); // Read the request body as a string var requestBody = await reader.ReadToEndAsync(); // Process the request body as needed Console.WriteLine(requestBody); } and set context.Request.EnableBuffering(); in program.cs or middleware.

[@sudidav]

Thanks for sharing. What happens if I have like 20 services?Does that means I will have to chain the AddProblemDetails() and the GlobalExpection extension on every service injection? How can I handle that?

[@juliocasal]

Could you clarify what you mean by "services"? You mean application services in your single app? Or you mean multiple microservices?

[@sudidav]

I mean if I have multiple repos services, will I e chaining the AddProblemDetails() and the GlobalExpection for each one of them or is there a better way to handle that? @@juliocasal

[@2u1u]

​@@juliocasalI believe because you chained the addproblemdetails to a addsignleton it looks like thr exception handler is attached to that Singleton. I believe it's attached to the service collection instead but the chaining looks like it's scoping the exception to the Singleton.

[@pt_trainer9244]

What's the best way to handle exceptions in microservices architecture? Can I create a shared project and reference the custom exception classes in each microservice? Is there a better approach ? Thanks

[@juliocasal]

Need to think a bit about this. Should be easy enough to have a global handler on each microservice, since each one might have their own custom exceptions.

[@DK-vh5kt]

A Nuget package could be also ok for this purpose to handle all logs to a service like elasticsearch .

[@GDWR2]

I don't like the idea of mapping all errors of one type (unless you have one custom type specially for this) into an error message, especially when it's a stdlib exception. It feels like info could be leaked accidently and it should be done within the api endpoint handler explicitly. This also means the valid responses (I am also meaning the errors) are contained in one place and accessible to developers rather than hidden and magic. Thanks for the video, was good.

[@juliocasal]

That's fair. I used standard exceptions just to keep things simple, but you can use all sorts of custom exceptions there. You have full control of how each exception is mapped, so there should be no accidental leaks. Also, using a global exception handler is a very standard practice, so I don't think it's hidden and magic. Glad you liked the video!

[@brijesh1596]

Really useful stuff.Thanks! btw is that code completion coming from copilot or some VS extension?

[@juliocasal]

Thanks! That's Copilot.

[@ivanaradenkovic4638]

Thanks :)

[@juliocasal]

Welcome!

[@DisturbedNeo]

It's cool that the .NET team is formally supporting this commonly used pattern, but I don't like that it always catches _all_ exceptions, and the only way to handle specific types of exception is via reflection. If I could specify an exception type as a generic type argument for the "UseExceptionHandler" method, something like "UseExceptionHandler()", that would be ideal. Maybe in .NET 9.

[@juliocasal]

Great feedback! If you get a chance, you can always provide direct feedback here: github.com/dotnet/aspnetcore