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.
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.
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.
@@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!
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.
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)`.
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 :)
