I'm not a big fan of having the service decide which HTTP error the handler returns if something goes wrong. Let's say we have a service that manages invoices and a method that returns a given invoice based on it's id. If that invoice doesn't exist in my opinion we should not return an error that is automatically mapped to 404 in a handler because depending on the context a 403 or even 5xx might be a better response. Errors returned by services should be specific to the service and the handler should decide how to map those errors to HTTP status codes not the service.
I agree - I have since been bitten by this and now take the exact approach you’ve mentioned! I’ll make an updated video on this soon as I think it’s a very key point!
Most impressive. Not only was this video clear and informative, I can tell you know what your talking about by how fluid you are in talking about it. Well done.
@@khushalgandhi5157 i think pretty much all languages from the past 15years, rust would be a good mainstream example. As for what changes in golang well support for sum types would be the first thing for me. Then maybe optimized/release builds.
@@TehGettinq I am a new golang dev working for past 5 months using fiber and gin framework Do u suggest any other language that I should learn on my own . I know the basics of Java
@@khushalgandhi5157 That's great :) I would say 5 months is not a lot if you are new. If you enjoy golang I would say keep using it and make sure you understand and study all the technical details (go routines, channels, interfaces, packaging).. Then once you feel like you are extremely comfortable with these concepts you can move to something else!
Damn, this is nice. Imho it would be perfect if you finish it off with some dependency injection, specific error handler interface which is later on implemented by a few packages, http, grpc... So then when you switch from httperror to grpcerror you do it in one place by replacing the structure instead of refering to a different package everywhere :)
So much code and you are still going to end up with thousand lines of "if err != nill" When people are asking for better error handling I am not sure that we worry about how to transfer error details, but rather how to make the code cleaner and less repetitive.
Hi! There is indeed a new `Join` method in the standard library `errors` package. pkg.go.dev/errors#example-Join But looking back on this code, error wrapping is probably nicer here. `fmt.Errorf("%w: %w", err1, err2)`.
I'm kinda lost, why do you put errors.go under service? wouldn't it be more intuitive to put it under commons / helper? because it's the more generic error, am i right? thanka in advance
depends, but pkg like commons and helpers are totaly useless name conventions saying nothing, in this case it could be at /service/errors/http.go when he was talking about rpc potentional implementing.
Hello! Thanks for watching :) No need to use it if you'd like more control on an error by error basis from your services, however the switch for the HTTP codes is a mere util to return HTTP status codes from a server based on errors returned from your services - idea being saving repetitive response code handling code throughout your endpoints. Hopefully that makes sense :D
@@clutchmadness The second principle of SOLID or Open-closed Principle. If we add a new "Error" then we will have to modify this SWITCH as well. To avoid this necessity, use polymorphism instead of SWITCH. The behavior must be transferred to the method of the "Error" file, and instead of SWITCH, the method from these files will be called. It is necessary to save the condition of the presence of a certain method in each file, an interface can help with it.
Jesus dude I’ve been looking for Go content like this. I’m going to binge watch all your videos. Keep it going.
Thanks for the comment! Much appreciated :) - More videos coming soon!
I'm not a big fan of having the service decide which HTTP error the handler returns if something goes wrong.
Let's say we have a service that manages invoices and a method that returns a given invoice based on it's id. If that invoice doesn't exist in my opinion we should not return an error that is automatically mapped to 404 in a handler because depending on the context a 403 or even 5xx might be a better response.
Errors returned by services should be specific to the service and the handler should decide how to map those errors to HTTP status codes not the service.
I agree - I have since been bitten by this and now take the exact approach you’ve mentioned! I’ll make an updated video on this soon as I think it’s a very key point!
underrated channel
Ayyy thank you!
Most impressive. Not only was this video clear and informative, I can tell you know what your talking about by how fluid you are in talking about it. Well done.
Thank you very much for you comment!
So good! Thanks for being the senior I don't have
Thanks for the video will implement it in a current project
Thanks for watching!😊
Beautiful! Earned a sub, thanks bro!
Thanks, this is useful
Thanks for watching!
you're an superstart bro😃😃
This is a great pattern, I had recently just done something similar on a recent project
Nothing better than handling errors nicely right!? - Thanks for watching :)
Great and useful content as always
Thanks again!
which font is this
I also end up doing similar stuff for generic-ish error handling. Sadly the only thing this truly highlight is how poorly designed go is.
Which language do u think has better error handling ?
What changes could be made in golang ?
@@khushalgandhi5157 i think pretty much all languages from the past 15years, rust would be a good mainstream example.
As for what changes in golang well support for sum types would be the first thing for me. Then maybe optimized/release builds.
@@TehGettinq I am a new golang dev working for past 5 months using fiber and gin framework
Do u suggest any other language that I should learn on my own . I know the basics of Java
@@khushalgandhi5157 That's great :) I would say 5 months is not a lot if you are new. If you enjoy golang I would say keep using it and make sure you understand and study all
the technical details (go routines, channels, interfaces, packaging).. Then once you feel like you are extremely comfortable with these concepts you can move to something else!
@TehGettinq Maybe I am missing something, but do you mean an option type that can return a Some or None, or what do you mean by sum type?
thank you, your channel make my go code more clean 😊
Thank you for watching, I'm glad the videos are helping! :)
Good job!
Thanks! 😊
Damn, this is nice. Imho it would be perfect if you finish it off with some dependency injection, specific error handler interface which is later on implemented by a few packages, http, grpc... So then when you switch from httperror to grpcerror you do it in one place by replacing the structure instead of refering to a different package everywhere :)
Hey man, would you mind sharing your font and theme? Nice video. Thanks
Thank you man! The theme is "gruvbox", but I also switch to "catppuccin". My go to font is "Monaco" :)
Thank you very much. I will subscribe.Keep it up! @@samvcodes
So much code and you are still going to end up with thousand lines of "if err != nill"
When people are asking for better error handling I am not sure that we worry about how to transfer error details, but rather how to make the code cleaner and less repetitive.
Where did you get the Join function? Because in errors there is no Join function.
Hi! There is indeed a new `Join` method in the standard library `errors` package. pkg.go.dev/errors#example-Join
But looking back on this code, error wrapping is probably nicer here. `fmt.Errorf("%w: %w", err1, err2)`.
@@samvcodes tks
I'm kinda lost, why do you put errors.go under service? wouldn't it be more intuitive to put it under commons / helper? because it's the more generic error, am i right? thanka in advance
Bruz… if that’s all you picked up from this video, you’ve got 100 problems
depends, but pkg like commons and helpers are totaly useless name conventions saying nothing, in this case it could be at /service/errors/http.go when he was talking about rpc potentional implementing.
Please make a video on mocking
Will do!
Mate we need full beginner friendly tutorial of go from you. Please 🚀❤.
Coming soon😊 thanks!
But also more intermediate/advanced stuff as well. Theres a huge supply of beginner content and not nearly enough more advanced content
full beginner content is everywhere out there. intermediate stuff would be way more useful at this point
Please drop the repo
get rid of the "SWITCH", it spoils everything
Hello! Thanks for watching :)
No need to use it if you'd like more control on an error by error basis from your services, however the switch for the HTTP codes is a mere util to return HTTP status codes from a server based on errors returned from your services - idea being saving repetitive response code handling code throughout your endpoints. Hopefully that makes sense :D
@@samvcodes move the behavior to where it should be and do not write "SWITCH" where it is not needed
Where is he supposed to move it? @@oleksandr-petrovych
@@clutchmadness The second principle of SOLID or Open-closed Principle.
If we add a new "Error" then we will have to modify this SWITCH as well.
To avoid this necessity, use polymorphism instead of SWITCH.
The behavior must be transferred to the method of the "Error" file, and instead of SWITCH, the method from these files will be called.
It is necessary to save the condition of the presence of a certain method in each file, an interface can help with it.
@@oleksandr-petrovych Thank you for explaining.