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

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hey guys Sam I'm here today I wanted to go through handling errors in your service pattern in goang um so I'm assuming everyone knows what a service pattern is but um very very quickly we have a service type which is our service this service could have you know databases embedded into it it could have your logo all types of stuff just embedded into that service um and then you have methods on it which are your service methods so these are kind of like your um your actual application code for a bit of logic in a service right so for example if you had a user microservice you might have a sign up method on it right and the idea is you would pass your whole service along with its methods obviously over to a HTTP server or a grpc server and the idea is again you wouldn't want to have to change your service if you are changing dependency so you wouldn't want to change like you wouldn't want to change any code in the signup method if we're going to send pass this over to um a http server and we wouldn't want to change it again if we passed it over to GPC so that what I've had problems with with that is then errors how am I going to handle this being a bad request and then also gopc and others uh know how to understand that right so um this is where generic errors come in right so here's a series of generic errors and error bad requests and error internal failure eror not found right these are typically your common response codes say in http G RPC servers right so you would have a 4 400 bad request in in HTTP server or you might have a failure which is a 500 internal um but obviously uh your rest server your HTTP server and GOC server will handle these differently so this is the nice thing we can do so F firstly you could keep this really simple and I'm assuming everyone's heard of error wrapping so you can wrap in your generic errors so you could wrap in here by request right so now we know that if someone provides an invalid email into our service method it's a bad request so what we can then do in our rest server and in our HTTP server is then we could go into that so let's just pretend this is a rest server you know we could then say if errors. is error service. error B request then you know return a HTTP uh Forex code right so that's a very simple solution to that straight away but um some something I've been doing recently which I think is has worked really nicely for me um is to actually create a error type so obviously an error in go is just an interface that implements the error method which returns a string so what we can actually do is we can embed our application error so our genuine error we get from you know um in the service right and then also we could embed a a service error so we're considering a service error as one of these generic error messages here um so what you can do here is we can have a function new error which takes in our service error and it takes in an app error and obviously it's just going to return an error right cool so you can't use error of course because at the moment we need to go and Implement that error interface like so uh we just want to return a string and what you can do here is there's multiple ways of doing this but a very quick one I like to do is just errors. jooin and then what we can do here is e do service error and E do apppp error and then that way in your error message you actually get you know bad request and the reason right um oh that's because that returns an error oh and then yeah easy way to do that is just to then call the error method on that cool so a bit bit hacky there but um bear with me okay so we have a validate email function so let's just use that very quickly um typically in like you know domain driven design we would actually have that as like a domain validation thing but we're not using domain driven design in this context um so we have a valid email and we have an error right so really easily now what we can say is if AR is not equal to nil go ahead and return a uh new error which should be our service error so we could say you know error bad request and then also the application error right uh is not used but that's fine cool so we've now associated a bad request with this error so we now know if we pass this to http or grpc that it's a bad request right this is where leads me on to the final thing that's quite cool about this little error handling method okay so what we want to basically do now is we've got an error HTTP package and we want to convert the error using errors. as which the errors package and go has some really nice stuff um and what this basically does is it takes an error and it just tries to almost cast it to our or type set I suppose to our service error type and this as function will only turn return true if it can actually do so um so we need a couple of methods right we need a a method to get the app error and then obviously as you probably guessed we're going to need one to go and return a service error so we have a service error cool okay so I'm going to walk you through now exactly what else I've just done right so essentially what I've done is I've used the app error to go ahead and set our message on our API error response field and I've also made a switch on our service error to then set the HTTP code on our service correctly right so the nice thing about this now is we have a service that returns generic errors such as a bad request and it simply embeds a the actual error and a generic error together so now if if we pretend again this is our HTTP server all you need to do here is actually you know obviously you can't return from a main function but what you would actually do is HTTP error uh do from error and you would return just pass in your error and that would go ahead and return you uh that would go ahead and set the status code correctly obviously if your server was set up to actually read the API error and the message right so the really cool thing about this and the and why I think this is a really nice way of handling errors in your service methods is you suddenly might need to expose a grpc server to your service right and you don't want to have to go through again obviously your service and replace all those errors to be grpc specific so you would simply just add you know a grpc error package and you would have a from error from service error whatever you want to call it function that again would just you know use errors. as get it into your service error type um go ahead and set grpc statuses correctly so you only change if suddenly we had to swap this out to be you know to handle grpc errors from this service method would be grpc error from your service error right so yeah hopefully this is a quick quick enough video um I wanted to share it because this worked really well in some projects I've worked on and I'm hoping that it would do the same for you guys as well if you use the service pattern in goang um let me know if there's anything you don't like about it put it in the comments below uh but hopefully you get some value out of this error handling pattern um it works quite nicely for me like I say so yeah leave a like if you enjoyed and I'll see you later on
Info
Channel: samvcodes
Views: 22,507
Rating: undefined out of 5
Keywords:
Id: CxcxRgwWtAk
Channel Id: undefined
Length: 7min 42sec (462 seconds)
Published: Sun Oct 08 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.