Handling errors LIKE a 10x ENGINEER in Golang - Golang Service Pattern

In this video, I discuss handling errors when using the Service Pattern within Golang. Specifically, I talk about writing a generic service error package that can be used throughout your application to save from manually catching specific errors throughout your HTTP / gRPC / any other "adapter" your service may use.
This has personally saved me lots of pain with services that expose both an internet-facing HTTP endpoint and a gRPC internal method, saving me from having to write any code to convert errors to match the transport method.
Let me know what you think, and of course, let me know if you have any nice ideas on how you get around this problem in your Golang services.
Twitter: / samvcodes
Tiktok: / samvcodes

[@matthew1106]

Jesus dude I’ve been looking for Go content like this. I’m going to binge watch all your videos. Keep it going.

[@samvcodes]

Thanks for the comment! Much appreciated :) - More videos coming soon!

[@packagebattos]

underrated channel

[@samvcodes]

Ayyy thank you!

[@cole.maxwell]

So good! Thanks for being the senior I don't have

[@esra_erimez]

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.

[@samvcodes]

Thank you very much for you comment!

[@MatthiasFasching]

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.

[@samvcodes]

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!

[@leonardovillalobos5277]

Beautiful! Earned a sub, thanks bro!

[@rampandey191]

Thanks for the video will implement it in a current project

[@samvcodes]

Thanks for watching!😊

[@M-xl1vx]

Thats amazing

[@Ishmeetsinghis]

Thanks, this is useful

[@samvcodes]

Thanks for watching!

[@memeherp166]

thank you, your channel make my go code more clean 😊

[@samvcodes]

Thank you for watching, I'm glad the videos are helping! :)

[@afadeevz]

Great and useful content as always

[@samvcodes]

Thanks again!

[@konradpiotrowski9549]

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 :)

[@user-fx5li1cy5t]

Good job!

[@samvcodes]

Thanks! 😊

[@matthewrawlings6763]

This is a great pattern, I had recently just done something similar on a recent project

[@samvcodes]

Nothing better than handling errors nicely right!? - Thanks for watching :)

[@TehGettinq]

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.

[@khushalgandhi5157]

Which language do u think has better error handling ? What changes could be made in golang ?

[@TehGettinq]

​@@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.

[@khushalgandhi5157]

@@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

[@TehGettinq]

@@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!

[@diehenne]

@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?

[@Bashx1]

Hey man, would you mind sharing your font and theme? Nice video. Thanks

[@samvcodes]

Thank you man! The theme is "gruvbox", but I also switch to "catppuccin". My go to font is "Monaco" :)

[@Bashx1]

Thank you very much. I will subscribe.Keep it up! @@samvcodes

[@danimunf]

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

[@Laflamablanca969]

Bruz… if that’s all you picked up from this video, you’ve got 100 problems

[@filipboye-kofi3018]

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.

[@justiceessiel6123]

Please make a video on mocking

[@samvcodes]

Will do!

[@anhhaoam3379]

Where did you get the Join function? Because in errors there is no Join function.

[@samvcodes]

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)`.

[@anhhaoam3379]

@@samvcodes tks

[@justiceessiel6123]

Please drop the repo

[@gouravkolhatkar3623]

Mate we need full beginner friendly tutorial of go from you. Please 🚀❤.

[@samvcodes]

Coming soon😊 thanks!

[@vikingthedude]

But also more intermediate/advanced stuff as well. Theres a huge supply of beginner content and not nearly enough more advanced content

[@felixna5650]

full beginner content is everywhere out there. intermediate stuff would be way more useful at this point

[@oleksandr-petrovych]

get rid of the "SWITCH", it spoils everything

[@samvcodes]

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

[@oleksandr-petrovych]

@@samvcodes move the behavior to where it should be and do not write "SWITCH" where it is not needed

[@clutchmadness]

Where is he supposed to move it? @@oleksandr-petrovych

[@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.

[@clutchmadness]

@@oleksandr-petrovych Thank you for explaining.