As always, great content! As a consultant, I often find myself not writing code full-time for months at a time. I love coming back to your channel to catch up. It's been a hot minute since I've had to worry about setting up global exception handling. This is clearly a demo, so you haven't tried to demonstrate every little detail, but I just wanted to sort of validate my thinking with you so that I'm sure I haven't missed out on a change. I would imagine that the goal would be to provide a message that is useful to the end-user without exposing potentially dangerous information. Given that, I would imagine that in the output payload, it would make sense to include information like where the user could go to get support along with some sort of logger or correlation ID that would allow the support staff or developers to find the exact log entry associated with the underlying exception.
Geat video. I wonder what is a good practice in terms of error handling in web API. I have try-catch in both the service methods and the controller actions and log the error in the service and throw it again so controller can catch it and log it. Should I always return a 500 response to client when there is an error.
You should let the user know something went wrong. That doesn't always mean a 500, but it does mean that you return some type of error code. Just don't return a 200 with a body that has an error message. That is a BAD practice.
Question I hope you can answer here Tim. With minimal APIs, if you use auto routing for parameters. i.e. app.MapGet("/book/{id}", (int id) => If you don't send an integer, this will result in a bad request but with no context and the method in the video will not catch this. Although if you run in development mode to show exceptions with trace, it does show. And you can't do any handling within the body because it's being caught before it even gets there. How can you give basic context back to the request, to say that it was expecting an int? I've found some methods that allow me to output some data, and I can use addproblemdetails to try add the exception message for those types of exception, but the exception is null in the problemdetails context.
I'm going off of my memory here, so I may be incorrect, but I believe the issue here is if you don't pass an int, you aren't actually calling that route. There's no exception inside of that route because that route wasn't called. It would either call just the /book route if you left the int off or it would call whatever route you specified if you included something besides an int like /book/test/. Either way, that would be handled at the routing level rather than the particular endpoint.
The purpose of this demonstration was not to show you what to put in your global exception handler or how to process a specific scenario. It was to show you how to set up a global error handler.
Hi @IAmTimCorey , awesome video as always , i have a video suggestion if you would consider it , How do you find a junior job in an overcrowded market , (I've got in deep in research there but this year it's going to be a nightmare finding a junior position , (side effect of overhiring juniors in 2022 and then letting half of them go early last year as far as i can figure it out) ) Any advice perhaps because after 3 months i am struggling to find even an unpaid internship. My best Nick
I'm not sure I understand your question. In this video, I am showing you how to catch errors at the global level (any unhandled exception from any endpoint) in case you don't handle them properly in your endpoint. An EndpointFilter wouldn't really change anything here. You could run a filter to check for bad data, etc., but that doesn't stop an unhandled exception and it doesn't address the issue across endpoints.
I freaking hate the minimal api pattern, and returning a 400 Bad Request indicated that there was something wrong with the request from the klients side as malformed xml or json so that would not be something you'd like to return if there was a server error.
You are mixing things up. The 400 wasn't a replacement for the 500. Returning the 400 from the endpoint was just an example when handling a specific known exception. Could have been something else; a 401 or 404 or whatever. Returning the 500 in the global exception handler was just an example for how to deal with any unknown exceptions you didn't handle in the endpoint. Didn't have to be a 500 either; the 500 was just an example as well. Btw, what's wrong with minimal API?
As @jakobjrgensen3223 pointed out, the point of this video isn't to tell you what to do inside of that global error handler (or the error handling in the endpoint). The point was to show you to that you could do something in those areas. What you do will depend on your situation. Trying to come up with the exact right thing to do in each would have greatly extended the video, would have made the demonstration less clear, and would not have covered every situation. As for hating minimal APIs, why? They are the new standard that most things are moving to. They are simpler to set up, have less overhead, and are actually faster as well (runtime performance, not just faster to build).
@@IAmTimCorey thanks I missed that, it's just a matter of opinion, I feel it's more cluttered and in compination with file-scoped namespaces it begins to be hard, at least to me, to read. Brackets are esensial for me to read code
That sounds like a topic for a video. I would recommend you work on a clear title and a really clear description of what you are looking to see and then you can add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/ Just be sure to clarify what you are asking for. Right now, I'm not certain I understand.
Man, this is so much nicer than rolling your own GEH.
Agreed.
As always, great content! As a consultant, I often find myself not writing code full-time for months at a time. I love coming back to your channel to catch up. It's been a hot minute since I've had to worry about setting up global exception handling. This is clearly a demo, so you haven't tried to demonstrate every little detail, but I just wanted to sort of validate my thinking with you so that I'm sure I haven't missed out on a change.
I would imagine that the goal would be to provide a message that is useful to the end-user without exposing potentially dangerous information. Given that, I would imagine that in the output payload, it would make sense to include information like where the user could go to get support along with some sort of logger or correlation ID that would allow the support staff or developers to find the exact log entry associated with the underlying exception.
Correct, that would be ideal.
Master, thank you for your valuable content and consistent work. The best, as always!
Thank you!
Geat video. I wonder what is a good practice in terms of error handling in web API. I have try-catch in both the service methods and the controller actions and log the error in the service and throw it again so controller can catch it and log it. Should I always return a 500 response to client when there is an error.
You should let the user know something went wrong. That doesn't always mean a 500, but it does mean that you return some type of error code. Just don't return a 200 with a body that has an error message. That is a BAD practice.
This was so simple. Thanks for such a clear cut video.
You are welcome.
Amazing video and simple example, thanks Tim!
You are welcome.
Question I hope you can answer here Tim. With minimal APIs, if you use auto routing for parameters. i.e. app.MapGet("/book/{id}", (int id) =>
If you don't send an integer, this will result in a bad request but with no context and the method in the video will not catch this. Although if you run in development mode to show exceptions with trace, it does show. And you can't do any handling within the body because it's being caught before it even gets there.
How can you give basic context back to the request, to say that it was expecting an int?
I've found some methods that allow me to output some data, and I can use addproblemdetails to try add the exception message for those types of exception, but the exception is null in the problemdetails context.
I'm going off of my memory here, so I may be incorrect, but I believe the issue here is if you don't pass an int, you aren't actually calling that route. There's no exception inside of that route because that route wasn't called. It would either call just the /book route if you left the int off or it would call whatever route you specified if you included something besides an int like /book/test/. Either way, that would be handled at the routing level rather than the particular endpoint.
As it seems to be a good practice that must have, why such is not included in the default template when creating a project?
Because different companies implement this differently. It is up to you to choose how best to set this up.
Would be nice to see how to implement the same pattern with gRPC and JsonTranscoding.
How did you get the colored braces? They look so cool, I want them.
Here you go: ruclips.net/video/td81h--afxM/видео.htmlsi=n6bbvSJ8c37qL5jc&t=1504
Can this implementation be done in separate class and referenced in Program.cs? just to keep things clean
Sure.
Why not return "application/problem+json" ?
The purpose of this demonstration was not to show you what to put in your global exception handler or how to process a specific scenario. It was to show you how to set up a global error handler.
Hi @IAmTimCorey , awesome video as always , i have a video suggestion if you would consider it , How do you find a junior job in an overcrowded market , (I've got in deep in research there but this year it's going to be a nightmare finding a junior position , (side effect of overhiring juniors in 2022 and then letting half of them go early last year as far as i can figure it out) ) Any advice perhaps because after 3 months i am struggling to find even an unpaid internship. My best Nick
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
why if using IEndpointFilters to handle the errors is it a bad approach ?
I'm not sure I understand your question. In this video, I am showing you how to catch errors at the global level (any unhandled exception from any endpoint) in case you don't handle them properly in your endpoint. An EndpointFilter wouldn't really change anything here. You could run a filter to check for bad data, etc., but that doesn't stop an unhandled exception and it doesn't address the issue across endpoints.
Thanks Tim!
You are welcome.
Seems very useful, thanks!
You are welcome.
Love your work
Thanks!
Thanks Tim...
You are welcome.
I freaking hate the minimal api pattern, and returning a 400 Bad Request indicated that there was something wrong with the request from the klients side as malformed xml or json so that would not be something you'd like to return if there was a server error.
You are mixing things up. The 400 wasn't a replacement for the 500. Returning the 400 from the endpoint was just an example when handling a specific known exception. Could have been something else; a 401 or 404 or whatever. Returning the 500 in the global exception handler was just an example for how to deal with any unknown exceptions you didn't handle in the endpoint. Didn't have to be a 500 either; the 500 was just an example as well. Btw, what's wrong with minimal API?
There is no point of using a MVC controller for JSON based API.
As @jakobjrgensen3223 pointed out, the point of this video isn't to tell you what to do inside of that global error handler (or the error handling in the endpoint). The point was to show you to that you could do something in those areas. What you do will depend on your situation. Trying to come up with the exact right thing to do in each would have greatly extended the video, would have made the demonstration less clear, and would not have covered every situation.
As for hating minimal APIs, why? They are the new standard that most things are moving to. They are simpler to set up, have less overhead, and are actually faster as well (runtime performance, not just faster to build).
@@IAmTimCorey thanks I missed that, it's just a matter of opinion, I feel it's more cluttered and in compination with file-scoped namespaces it begins to be hard, at least to me, to read.
Brackets are esensial for me to read code
Interesting stuff
Thanks!
Sir I am stuck with navigation in wpf for page to window then multiple windows , and closing of previous page can you guide me
That sounds like a topic for a video. I would recommend you work on a clear title and a really clear description of what you are looking to see and then you can add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/ Just be sure to clarify what you are asking for. Right now, I'm not certain I understand.
@@IAmTimCorey ok sir thank you...