Global Exception Handling in ASP.NET Core Web API (.NET 8)

[@CodeMaze]

Thank you all for watching and for your support. ►► If you want to check out all our courses you can do that here: courses.code-maze.com/courses/

[@andresbeltran5779]

This is one of the best channels rigth now, all the topics are super usefulls

[@CodeMaze]

Thank you Andres. I'm glad you think it that way. I'm sure I'll do my best to add as much videos with a quiality content as I can.

[@parko1965]

I noticed this in the new version of your book, it's a much cleaner way of centralising exception handling. Sometimes it's much better to hear the voice explaining what we are doing rather than just reading the book. Thank you for this video.

[@CodeMaze]

Thank you to, for the comment and for watching it. I agree sometimes it is a lot better to see the implementation in front of your eyes rather than just a full code.

[@islam.ahmed154]

Great content and very valuable I think here is the right place to become a better software developer. Thank you for this great effort.

[@CodeMaze]

You are very welcome. Thanks for watching the video.

[@andresbeltran5779]

I have a question, I vaguely remember seeing elsewhere that this new way of handling exceptions in .net 8 forced us to create a class per exception. I am not referring to exceptions that one wants to create, but to the middleware. I see that it can be handled in the same way as in previous versions, a single class with all the exceptions logic of the project and it returns true and that's it, does it work like that? Another thing that I am not very clear about is why it would return false? Maybe if I wanted to invoke another process in another class? greetings

[@CodeMaze]

Hi Andres. Well, if you want to have one class and handle multiple exceptions, like for example we do in our book where we have a single class inheriting from the IExceptionHandler and there we handle, NotFoundException, BadRequestException, etc... But, if you want to have some very specific logic for certain types of exceptions, I think it would be always better, if nothing at least more readable, to have multiple handling classes that you can register as services. Regarding the other thing, well it can be related to what I just wrote. If you have a class where you want to handle, for example BadRequestException with some special cases, you want to check in that class if you really got that type of exception, if not, you just want to return false and let the middleware continue and maybe some other class that you registered will handle that exception. You want to return true, only when you want that specific handler class to do its job.

[@andresbeltran5779]

@@CodeMaze got it

[@rvrunkillyow716]

What are use cases in using exception locally and globally? Thanks in advance.

[@CodeMaze]

I would always go with a centralized place to handle excpetions, without try-catch blocks in each action separately. Then, if you need some complex logic, you can customize your handler, extract classes with the logic, etc, but still, the base handling logic is in a single place. It reduces the code complexity in your actions and your business logic.

[@Mastersenseinew]

What is wrong with try catch anyway i dont get it I think this structure way more complicated for me yes u defines as ones but you eventually sending each exception same type of objects and 500 for all of them not a good idea in my opinion. İnstead of this I created genericresponsebase class and define error,notfound,success etc methods inside of it and whenever program catches the exception I pass arguments into error func all details and finally when the request finish I return IAction functions such as ok,notfound,badrequest etc.

[@Mastersenseinew]

And I want to understand something that what is differences between localy control and globally, is there any performance differences or just dry opinion clean arc behind of it

[@CodeMaze]

Hi. First of all, there is nothing wrong with try catch blocks, just having them in every action or every method is not the cleanest approach. Now, regarding your comment about 500 error all the time, in one part of the video I state this: "One thing to mention here. We are using the 500 status code for all the responses from the exception middleware, and that is something we believe should be done. After all, we are handling exceptions and these exceptions should be marked with a 500 status code. But this doesn't have to be the case all the time. For example, if you have a service layer and you want to propagate responses from the service methods as custom exceptions and catch them inside the global exception handler, you may want to choose a more appropriate status code for the response. You can watch about this technique in the Onion Architecture video, which you can find in the description below." So, I have the Onion Architecture video where this technique is used to return different status codes to the client. Everything you see in the global exception handler can be customized and extracted into own classes, if needed, so for me, this is always a cleaner approach - the way I use in all my projects. Also, I don't think there are any performance advantages for this approach, at least, not that I have noticed, but reagarding the cleaner actions and cleaner service layer methods - that's for sure.

[@Mastersenseinew]

​@@CodeMazethanks for the response great explanation

[@BobbyRock345]

Can you provide the code for Logger Service Library which you have implemented

[@CodeMaze]

Hi. The entire source code is part of the patreon membership. But the logger service has nothing with Global handler implementation, it just helps identifying the issues on production apps, so you can implement it the way you want.

[@10Totti]

Nice tutorial, is possible get code example ?

[@CodeMaze]

Hi. We still didn't prepare the way for sharing the source code over KZbin, but you can find the similar code (not the same) in the article on our site: code-maze.com/global-error-handling-aspnetcore/

[@orange_cat_energy]

different ways of exception handling: - Try-Catch Block - Built-In Middleware - Custom Middleware - IExceptionHandler (.NET 8) did i understand correctly?

[@CodeMaze]

Yes, something like that. Just the Try-Catch is not something you can use for the Global exception handling. As you can see, there are better ways for that.

[@Mastersenseinew]

​@@CodeMazebetter for which area performance, dry or something else can you explain it? If something wrong with it why Microsoft add this functionality at first place. Thanks

[@mrityunjaik]

please send the repository link for checking code

[@CodeMaze]

Hi. You can find the source code for all the videos as part of the patreon package. The link is in the description.

[@JohnSmith-yr7ih]

Thank you for your video but it in .net 8 it has been simplified.

[@CodeMaze]

Hi. Well, yes, I've shown three ways. The last one is the one that you can use in .NET 8 using the IExceptionHandler interface. I wouldn't say it is simplified, just now, you have an interface that you can inject as a service and can chain exceptions if you need that.