Get the source code for this video for FREE → the-dotnet-weekly.ck.page/error-handling Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
I think it might be worth to mention something about Exception Filters, I know they are a bit different but in general are also used to handle exceptions
@@MilanJovanovicTechI use exception filter all the time, you just have more content in the exception filter than exception middleware because they are called later after the pipelines
Hi Milan, this is a great tutorial for handling error globally. Of course, I would love to know some more complex functionality which we can make place inside some other subsequent middleware to make our code better.
Like. Unless you need to have additional data from failed request middleware is a good option. In other cases consider exception filters.btw: may be a nice topic middleware vs filter
Thanks for the great video. I think using the status code again in the body of the response is unnecessary duplicate. I also prefer to add a RefID in the response body which is linked to the error log. So, in case that the client contacted the support team, they can easily find the original error log.
It's not a unnecessary/duplicate. Why would the consumer of your API have to see the HTTP response code? We're giving them the ability to take a look at the response body, and have all of the relevant information.
Hi! thanks for your videos, are amazing. I have a question, (im sorry if its a bad one, I am a begginer ) I could add some others Catchs with particular exceptions and handle them each one in a particular way, with differentes codes an differentes ProblemDetails, or thats not the use for this kind of middleware? thanks!
Instead of manually serializing and setting the content type, I like to just use _await context.Response.WriteAsJsonAsync(problem);_ Really enjoying your videos BTW
@@MilanJovanovicTech What he is saying, why do serialization and setting the content type with those two lines of code, when the WriteAsJsonAsync method does both of those things? Great videos btw, and I love the WoW collection in the back
Great video Milan! Thank you for presenting these important topics. One observation: Instead of using two statements to write the json body in the response you could merge them in one statement. await context.Response.WriteAsJsonAsync(errorResponse); Also, why do you need to make the middleware a transient service? Can you please explain, I was sure this worked without needing to do this
very clear and good, but by this way all errors will have the same response can you indicate this point to me , what I should do to describe each type of error ..thanks
You have two options: - Use the middleware only for 500 internal server + return meaningful errors in controller - Throw custom exceptions (NotFound, BadRequest) from your code, and handle them in middleware and return appropriate response code
Yes, I have learned something new, but I can not tell that I master it. Your audience is not only composed by experts, but also by intermediate developers. I would be really interested in more details explanations or links on the documentations where we can find what you don't explain, because you assume that developers already know these fundamental concepts. It is an hard work, but this is how Brackeys has reached more than one million of followers for Unity3D tutorials.
Hey Francois, I really appreciate the feedback. To be honest, intermediate-to-senior level engineers are my intended target audience at the moment. Until I can master the skill of being able to explain concepts in even simpler terms. For documentation links, that's a great suggestion. I'll try to improve on that front.
Great tutorial Milan. I wonder if it would make sense to have an error tracking id, like a GUID or any unique id. That is, to pass it to LogError and also on the to the Title or Detail property of ProblemDetails object.
My comment seemed to be deleted before, but the StatusCodes class in the Microsoft.AspNetCore.Http namespace already has fields that are ints (no casting) for all the Http response codes you might want to return, and it also has the code with the description, which is good when dealing with the less common response codes.
Hi Milan, Great Tutorial. Could you make a tutorial on how to handle Errors on the client side. For example for a http client who can have a T Resposne or a problemDetails. I struggle to find an elegant way to handle both type of response. And maybe also how to handle it in an MVC or even better a blazor app. Thanks!
- why not return an application/json+problem as response content type? I missed that, to be honest - And maybe also how to handle it in an MVC or even better a blazor app You need some way to create a hook when an error happens, and you need to make your error responses generic for the entire API to be able to do that. If you always return a ProblemDetails, on the API consumer side that becomes doable.
In the middleware everything performs according to their presence in the sequence. Because we know that every component will execute after their prior component. In this video, you are putting exception handling(obviously as a middleware component) after executing other components of middleware. Have you think, it should be introduced at initial levels in the Program.cs
Hi Milan, if you place the middleware AFTER UseAuthorization\UseAuthentication then it won't cacth exceptions thrown by an AuthHanlder class for example. Shouldn't it go before UseAuthorization\UseAuthentication ?
Weird that your video appeared when it did. I had already applied option 2 to my API. But randomly, when I explicitly throw, or an unhandled error occurs, the middleware isn't catching it =/ I can see I enter the middleware fine, but it never enters the catch. Can you think of any reason why?
@@MilanJovanovicTech private readonly RequestDelegate _next; public ExceptionHandlingMiddleware(RequestDelegate next) { _next = next; } public async Task InvokeAsync(HttpContext context) { try { await _next.Invoke(context); } catch (Exception ex) { await HandleExceptionAsync(ex, context); } } Anything weird here you see? I see it goes into the try, go elsewhere in code get or throw error, but never goes inside the catch!
I followed the 2nd way in your tutorial step by step but got this error : "Unable to resolve service for type 'Microsoft.Extensions.Logging.ILogger' while attempting to activate 'WebApi.Middleware.GlobalExceptionHandlingMiddleware'". So i tried to add this : "builder.Services.AddTransient(typeof(ILogger), typeof(Logger)); " in the Program.cs but still not working. Do you have a solution ?
Can you make one video about Extending ProblemDetails, using with the above global error handling in which a developer can include the custom payload of an error information.
Hey thanks for sharing this. I have one question. I am using global exception handler in my project but some scenario i need to keep going even if i have exception. For example i have Mongo Database and SQL Database, If mongo fails for some reason (wrong conn string) and It comes to exception however i dont want to send back 500 status code in response because i have SQL database to query and send back data to the client. Please advise.
What about "UseExceptionHandler" ? It's cleaner for me to use "UseExceptionHandler", so you don't have to add the middleware to the serviceCollection and you dont have to put that try..catch block but good approaches 😁😁
What about aspnetcore web apps. There's a if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/Home/Error"); app.UseStatusCodePagesWithRedirects("/Home/Error/{0}"); } code to add. Do you have a video touching on this ? Thanks
I am trying to catch the Model Validation error where I get an 400 bad request when one of the fields have incorrect data like required validation or regex validation but I can't catch it a log it. I can use a middleware and get the request but the response returns as 200 status code and not 400 bad request so I can't differ between requests ... any ideas?
Place your custom middleware at the top of the middleware chain, so any exception thrown is propagated to it. Secondly, are you sure Model Validation throws an exception at all?
@@MilanJovanovicTech well, in the middleware I just use next.invoke and then if I check the Context.Reaponse.Body, I get the 400 status code on the validation error which sets as bad request. The problem is that I need to open a new MemoryStream for every request and then check for the status code and that's a bad practice that can cause a huge memory leak. I didn't find anything more elegant.
System.InvalidOperationException: 'An error occurred when configuring the exception handler middleware. Either the 'ExceptionHandlingPath' or the 'ExceptionHandler' property must be set in 'UseExceptionHandler()'. Alternatively, set one of the aforementioned properties in 'Startup.ConfigureServices' as follows..I am facing this issue
"the concept of middleware in asp.net core" is obviously not framework agnostic That's why I said it like that and not just "the concept of middleware"
There is no such thing as concept x in framework y. Middleware in .net are not different at the concept level from nestjs middleware and so on. If you want to talk about a concept it is important to note that the framework is insignificant.
@@MilanJovanovicTech absolutely, use it in all of your projects, every time that your product users get an error sentry tells you when and where, and which line of your code has an error and you can see every error that user sees with full detail
Very Interesting, thanks for the video Milan, looking forward for more content from you. Can you post a video of how to use the Ilogger to log the error to database or a file ?
Thanks for your videos Milan. Main question is about JsonSerializerOptions, how to easily get same json options configured by AddControllers() .AddJsonOptions() call? is it possible to share same settings also on middleware?
@@neociber24 One more question-> When to use object keyword vs dynamic keyword?. Both can be used to store some complex data at run time. Any advantage of using one over other
@@MarcusKaseder thanks a lot for your answer. Can u answer one more question-> the one reason of using var keyword is that it is short to write as compared to big data type. What is the other major reason to use var keyword????
Hey Mian, I love your video and they are so educational to me and I'm sure to others as well. I would like to ask your opinion on another video from Nick Chapsas which is quite intriguing. ua-cam.com/video/a1ye9eGTB98/v-deo.html What do you reckon on this? There seems to be a clear trade off when throwing exception and catching them as part of the global exception middleware.
With proper Client side validation - bad requests are highly unlikely to reach your API. So the only reason a bad request would happen is someone calling your API directly - so I'm fine with the tradeoff i'm making here, and throwing exceptions
your videos are good, but person who has only good knowledge of Dot net tech can understand your stuff. You explain it very fast it is tough to understand.
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/error-handling
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Thank you Milan...
This was a very clear and beautiful explanation.
Glad it was helpful!
I think it might be worth to mention something about Exception Filters, I know they are a bit different but in general are also used to handle exceptions
I haven't used them in practice to be honest, Middleware is what I default to
@@MilanJovanovicTechI use exception filter all the time, you just have more content in the exception filter than exception middleware because they are called later after the pipelines
Hi Milan, this is a great tutorial for handling error globally. Of course, I would love to know some more complex functionality which we can make place inside some other subsequent middleware to make our code better.
Good point Sagar, I'll see what I can do
You make concepts very easy
Thank you!
Excellent video!
But, could you tell what's the benefit of using 3rd approach here?
Strong typing
Like. Unless you need to have additional data from failed request middleware is a good option. In other cases consider exception filters.btw: may be a nice topic middleware vs filter
That's certainly a nice topic to explore!
how simple and efficient, really good job.
Thank you!
Thank you, Milan. I'm using your example in a new project. It's already helpful.
You are welcome!
Great video, thanks , is there any particular reason to add the middleware as Transient why not scoped?
Scoped only makes sense if you need a scoped service inside
@@MilanJovanovicTech Could you please elaborate on "if you need a scoped service inside"?🤔😅
Thanks for the great video.
I think using the status code again in the body of the response is unnecessary duplicate.
I also prefer to add a RefID in the response body which is linked to the error log. So, in case that the client contacted the support team, they can easily find the original error log.
It's not a unnecessary/duplicate. Why would the consumer of your API have to see the HTTP response code?
We're giving them the ability to take a look at the response body, and have all of the relevant information.
@@MilanJovanovicTech There is an http status in the response header
@@AmjadKhateeb www.rfc-editor.org/rfc/rfc7807
@@MilanJovanovicTech Thanks. The explanation is very clear in the document. I didn't know that there is such a standard.
Hi! thanks for your videos, are amazing. I have a question, (im sorry if its a bad one, I am a begginer ) I could add some others Catchs with particular exceptions and handle them each one in a particular way, with differentes codes an differentes ProblemDetails, or thats not the use for this kind of middleware? thanks!
No bad question on this channel :)
Yes, you can definitely do that. A global exception handler based on exception type. 👌
Great video
One Question
Why you registered GlobalExceptionHandlingMiddleware as Transient not Scoped?
Since I don't inject any Scoped services, it can be Transient
Nice work, Milan Jovanovic!!!
How to use middelware to make filters, orderby and pagination???, Thank u.
Regards.
No idea
The 3rd option was new learning for me and enjoyed the custom JSON response throwing most! Thanks, @Milan Jovanović for your community effort!
You're most welcome! 😁
Milan... How to configure an inline watch in your visual studio, could you tell us?
ReSharper
@@MilanJovanovicTech thanks 🙏🏻👍🏻
Great stuff, thanks very much Milan.👏
Glad you liked it!
i liked your way of explanation, thank you.
You are most welcome
What do you think about Exception filter instead of middleware for error handling?
Middleware is usually simpler
Hey, can you shed some light on use of AddTransient vs AddScoped in this case?
learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#service-lifetimes
This is very good example of
Thanks!
Great tutorial, thanks Milan.
Glad you liked it!
Instead of manually serializing and setting the content type, I like to just use _await context.Response.WriteAsJsonAsync(problem);_ Really enjoying your videos BTW
You're writing to a Response which is in memory. Nothing too asynchronous there.
@@MilanJovanovicTech What he is saying, why do serialization and setting the content type with those two lines of code, when the WriteAsJsonAsync method does both of those things? Great videos btw, and I love the WoW collection in the back
Great video Milan! Thank you for presenting these important topics.
One observation: Instead of using two statements to write the json body in the response you could merge them in one statement.
await context.Response.WriteAsJsonAsync(errorResponse);
Also, why do you need to make the middleware a transient service? Can you please explain, I was sure this worked without needing to do this
With the IMiddleware approach you do. Otherwise it's fine.
This is cool. Please can you drop the github public repo for your videos? It will really be helpful
I share the code with my Patreon supporters, but I'm sure you can dig up something similar on my github:
github.com/m-jovanovic
very clear and good, but by this way all errors will have the same response can you indicate this point to me , what I should do to
describe each type of error
..thanks
You have two options:
- Use the middleware only for 500 internal server + return meaningful errors in controller
- Throw custom exceptions (NotFound, BadRequest) from your code, and handle them in middleware and return appropriate response code
@@MilanJovanovicTech, oh right, thanks
@@MilanJovanovicTech ,please can you have an example or demo to view this point,I understand it but need to show in practice
Yes, I have learned something new, but I can not tell that I master it. Your audience is not only composed by experts, but also by intermediate developers. I would be really interested in more details explanations or links on the documentations where we can find what you don't explain, because you assume that developers already know these fundamental concepts. It is an hard work, but this is how Brackeys has reached more than one million of followers for Unity3D tutorials.
Hey Francois, I really appreciate the feedback.
To be honest, intermediate-to-senior level engineers are my intended target audience at the moment. Until I can master the skill of being able to explain concepts in even simpler terms.
For documentation links, that's a great suggestion. I'll try to improve on that front.
@@MilanJovanovicTech Many thanks.
Great tutorial Milan.
I wonder if it would make sense to have an error tracking id, like a GUID or any unique id. That is, to pass it to LogError and also on the to the Title or Detail property of ProblemDetails object.
We can add a middleware that sets a Request Id header for each request
@@MilanJovanovicTech thanks for the reply. I'll try that out
My comment seemed to be deleted before, but the StatusCodes class in the Microsoft.AspNetCore.Http namespace already has fields that are ints (no casting) for all the Http response codes you might want to return, and it also has the code with the description, which is good when dealing with the less common response codes.
Absolutely Steve, that's what I usually use with Swagger's [ProducesResponseType]
Great tutorial Milan.thanks
You're welcome, glad you liked it!
excellent video Milan (y) Thanks
Glad you think so 😁
Hi Milan, Great Tutorial. Could you make a tutorial on how to handle Errors on the client side. For example for a http client who can have a T Resposne or a problemDetails. I struggle to find an elegant way to handle both type of response. And maybe also how to handle it in an MVC or even better a blazor app. Thanks!
Also, why not return an application/json+problem as response content type?
- why not return an application/json+problem as response content type?
I missed that, to be honest
- And maybe also how to handle it in an MVC or even better a blazor app
You need some way to create a hook when an error happens, and you need to make your error responses generic for the entire API to be able to do that. If you always return a ProblemDetails, on the API consumer side that becomes doable.
ExceptionHandlingMiddleware switch need to add OrderNotFoundException, Write it every time?
You can create a base NotFoundException and catch that one
In the middleware everything performs according to their presence in the sequence. Because we know that every component will execute after their prior component. In this video, you are putting exception handling(obviously as a middleware component) after executing other components of middleware. Have you think, it should be introduced at initial levels in the Program.cs
You're welcome to apply the ordering you want. Most middleware doesn't throw exceptions until we get to our actual request handler
Great Tutorial ! Thanks😍
Happy to help!
Great Tutorial ! Thanks :)
Glad it was helpful!
Thank you, Very useful, i learned lot from this.
Glad it was helpful!
Great Great content! Thank you so much Milan.
Glad you liked it!
Thank you
You're welcome!
it was simple and awesome.
Glad you liked it!
Nice one as usual😀
Thanks again!
When i do return BadRequest this code dont catch... Is correctly ?
Yes
Hi Milan, if you place the middleware AFTER UseAuthorization\UseAuthentication then it won't cacth exceptions thrown by an AuthHanlder class for example. Shouldn't it go before UseAuthorization\UseAuthentication ?
Yes
@@MilanJovanovicTech Why with the 3rd option did you register the ExceptionMiddleware with Transient scope? ChatGPT says it should be singleton 🙂
Thanks a lot 🎉
Always welcome
Great stuff. keep up the good work.
Thanks a lot! 😁
@milan I wish you had explained the sequence of middlewares invocation; how order matters
Doesn't the visual explanation at the start illustrate the concept? 🤔
@@MilanJovanovicTech Kind of. But what happens when I mix IMiddleware and non IMiddleware implementation?
@@nayanchoudhary4353 Both approaches work, the order they are registered in is the order in which they execute
Hello,1:18 three middleware is just an example or it is 3 middleware between request and respone?
It's one middleware - implement in three different ways
@@MilanJovanovicTech thank for you answer
I think, if we will put this middleware at the start of the pipeline we can log unhandled exceptions from other middleware
That is indeed the case
Weird that your video appeared when it did. I had already applied option 2 to my API. But randomly, when I explicitly throw, or an unhandled error occurs, the middleware isn't catching it =/ I can see I enter the middleware fine, but it never enters the catch. Can you think of any reason why?
Which exception are you catching?
@@MilanJovanovicTech Just the base "Exception" exact same code as you and everyone else on the internet has done when writing about this :D
@@GarethDoherty1985 Could be something around invoking the RequestDelegate
@@MilanJovanovicTech
private readonly RequestDelegate _next;
public ExceptionHandlingMiddleware(RequestDelegate next)
{
_next = next;
}
public async Task InvokeAsync(HttpContext context)
{
try
{
await _next.Invoke(context);
}
catch (Exception ex)
{
await HandleExceptionAsync(ex, context);
}
}
Anything weird here you see? I see it goes into the try, go elsewhere in code get or throw error, but never goes inside the catch!
@@GarethDoherty1985 That is entirely wild 😱
I have no idea why it's behaving like that
Awesome video, great explanation!!
Glad you liked it!
I followed the 2nd way in your tutorial step by step but got this error : "Unable to resolve service for type 'Microsoft.Extensions.Logging.ILogger' while attempting to activate 'WebApi.Middleware.GlobalExceptionHandlingMiddleware'". So i tried to add this : "builder.Services.AddTransient(typeof(ILogger), typeof(Logger)); " in the Program.cs but still not working. Do you have a solution ?
services.AddLogger? 🤔
@@MilanJovanovicTech oh gosh i didn't know there was such a service. Thank you bro ;-D
Can you provide a video on c# creating custom attributes for class, method and variable
Great suggestion!
Can you make one video about Extending ProblemDetails, using with the above global error handling in which a developer can include the custom payload of an error information.
ProblemDetails already has an Errors property which is a dictionary, and you can extend it freely
Applies to Blazor ?
I don't think so
nice video but just for very beginners! you could dig more into various ways of global error handling and come up with a nice fancy way dude :)
Do we need anything more complicated than the basics?
Hey thanks for sharing this. I have one question. I am using global exception handler in my project but some scenario i need to keep going even if i have exception. For example i have Mongo Database and SQL Database, If mongo fails for some reason (wrong conn string) and It comes to exception however i dont want to send back 500 status code in response because i have SQL database to query and send back data to the client. Please advise.
Well you need to handle this with some sort of decorator on your data access code
Hi Milan as Always this is helpful ... How can we ensure the exact status code and description for problem detail ?
What do you mean by "exact"? Do you want the status code to be dynamic based on the exception?
Yes i mean the status code
@@birukayalew3862 We have to catch the specific exception in the middleware, and set the appropriate status code
What about "UseExceptionHandler" ?
It's cleaner for me to use "UseExceptionHandler", so you don't have to add the middleware to the serviceCollection and you dont have to put that try..catch block
but good approaches 😁😁
That's also a nice option, definitely
What about aspnetcore web apps. There's a if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
app.UseStatusCodePagesWithRedirects("/Home/Error/{0}");
} code to add. Do you have a video touching on this ? Thanks
I don't, no
I am trying to catch the Model Validation error where I get an 400 bad request when one of the fields have incorrect data like required validation or regex validation but I can't catch it a log it. I can use a middleware and get the request but the response returns as 200 status code and not 400 bad request so I can't differ between requests ... any ideas?
Place your custom middleware at the top of the middleware chain, so any exception thrown is propagated to it.
Secondly, are you sure Model Validation throws an exception at all?
@@MilanJovanovicTech well, in the middleware I just use next.invoke and then if I check the Context.Reaponse.Body, I get the 400 status code on the validation error which sets as bad request. The problem is that I need to open a new MemoryStream for every request and then check for the status code and that's a bad practice that can cause a huge memory leak. I didn't find anything more elegant.
Hi
As a note, on the blog its missing the third option code.
Isn't it this:
www.milanjovanovic.tech/blog/3-ways-to-create-middleware-in-asp-net-core#adding-factory-based-middleware
Awesome content
I'm glad you liked it :)
Interesting, y set ContentType after sending response? that might works for you:(
Mistake, fixed that in post
why did you register it as a transient service not scoped ?
Because it's stateless
@@MilanJovanovicTech could you please explain what do you mean by stateless ?
Thanks :)
Sure thing
System.InvalidOperationException: 'An error occurred when configuring the exception handler middleware.
Either the 'ExceptionHandlingPath' or the
'ExceptionHandler' property must be set in 'UseExceptionHandler()'. Alternatively, set one of the aforementioned properties in 'Startup.ConfigureServices' as follows..I am facing this issue
I have no idea how you got that
awesome
Thanks!
Mine seems to not have triggered the exception even when it threw an exception
How so?
Excellent
Thanks
On minute 0:19 you say the concept of middleware in asp.net core but concepts (e.g middleware) are framework agnostic.
"the concept of middleware in asp.net core" is obviously not framework agnostic
That's why I said it like that and not just "the concept of middleware"
There is no such thing as concept x in framework y. Middleware in .net are not different at the concept level from nestjs middleware and so on. If you want to talk about a concept it is important to note that the framework is insignificant.
thx!
Any time!
How can you return errors using Error Codes along with messages that are translated based on the language?
IStringLocalizer: learn.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-8.0
Awesome
Thank you!
can you share source code
It's shared on Patreon
don't forget to use sentry in your project
I've never used it to be honest. Should I take a look?
@@MilanJovanovicTech absolutely, use it in all of your projects, every time that your product users get an error sentry tells you when and where, and which line of your code has an error and you can see every error that user sees with full detail
@@regestea like … an … exception? 😊
@@ryan-heath maybe 😁
What if exceptions are thrown for 404 or other status code?
How will you know it's thrown for 404 status code?
@@MarcusKaseder Right, that's the idea!
Exception.ToString() is bulletproof
Amazing
Thanks
Very Interesting, thanks for the video Milan, looking forward for more content from you. Can you post a video of how to use the Ilogger to log the error to database or a file ?
I'll add it to my list, sure 😁
for every error you are returning 500 code. I think it is not good for use case.
This is a fail-safe for unhandled exceptions. What else would you return?
@@MilanJovanovicTech can be 404 sometimes can be 400 error. dependens on the case.
Thanks for your videos Milan. Main question is about JsonSerializerOptions, how to easily get same json options configured by AddControllers() .AddJsonOptions() call? is it possible to share same settings also on middleware?
I think a better option would be create a static field with JsonSerializerOptions and use the inside of the middleware
@@MilanJovanovicTech I will try to inject IOptions and let you know!
Can anyone tell when to use "is null" vs == while comparison
Always use "is null" because the operator == can be override.
But to be real, rarely someone override the equality operator, maybe library authors
"is null" reads better. What Fredd mentioned is correct. But in 99% of use cases, this won't happen.
@@neociber24 One more question-> When to use object keyword vs dynamic keyword?. Both can be used to store some complex data at run time. Any advantage of using one over other
@@MarcusKaseder thanks a lot for your answer. Can u answer one more question-> the one reason of using var keyword is that it is short to write as compared to big data type. What is the other major reason to use var keyword????
@@MarcusKaseder thankyou so much sir. One last question how many years of .net development experience u have???
That's how to do a tutorial!
Thank you!
Hey Mian, I love your video and they are so educational to me and I'm sure to others as well. I would like to ask your opinion on another video from Nick Chapsas which is quite intriguing.
ua-cam.com/video/a1ye9eGTB98/v-deo.html
What do you reckon on this? There seems to be a clear trade off when throwing exception and catching them as part of the global exception middleware.
With proper Client side validation - bad requests are highly unlikely to reach your API. So the only reason a bad request would happen is someone calling your API directly - so I'm fine with the tradeoff i'm making here, and throwing exceptions
your videos are good, but person who has only good knowledge of Dot net tech can understand your stuff. You explain it very fast it is tough to understand.
Well, I only care about speaking to a .NET audience 🤷♂️
This is Wendy's sir 😂
I like your videos, but please stop with the zoom inn and out. Looks better without it.
It's only in the first 30s, come on 🙄🙄🙄
context.Response.WriteAsJsonAsync
If that's your only concern, I'll gladly take it