Golang Error Handling is TRASH!!! Here's how to fix it

as much as we would like it to be the case go surprisingly is actually not a perfect programming language even though go has plenty of selling points such as being generally performant greater concurrency support great weapon development support lightning fast compilation speed and the list goes on there are still some aspects of go that can receive a little bit of attention a little bit more with fitment in one of the ghost's developer survey it has a come to a clear conclusion that things like generics things like better error handling are some of the most critical language features that go developers are looking for as the generics has become readily available for gold developers which came with the 1.18 release a couple months ago it now begs the question of when are we going to see the very next most requested critical feature which is a better error handling to be added to the language as well now remember that even for generics which is a feature many hergo developers were dying for the proposal had to jump through so many hoops at some point i really thought that generics was never going to be part of the language so what about error handling is the go team actively working on addressing this problem or are we stuck writing endless amount of if statements checking if error is not equal to nil in today's video we will go through a few active proposals that have the most amount of traction and see how we can potentially fix error handling in gold [Music] what's up ninjas and welcome back to the golang dojo your number one resource for all things go make sure to get your free golang cheat sheets out of golandojo.com slash cheat sheet first let me clarify what the potential problem is let's say that we have a function that helps us construct the error that we want to potentially return additionally we have a function here that performs some type of vibrations and under some circumstances it will return an error as the result of this a particular function on top of that we have some other functions that perform a different set of operations but under again some circumstances it returns the same type of error in the main function we can make these function calls however as you can notice that we do get these areas of return which we need to handle as well to handle these errors that we would have to create these if statements as you can see right here and check if the error is not new then we will have some type of logic to handle the error and same therefore the error coming from the some other function as well even though the errors will return from these two functions it may have been the same type of errors we would still have to handle them as separately unfortunately now notice that this is only an example with two functions and we can already see these if statements are for error handling cluttering our program just imagine as our programmer grow in size in the near future we would have to keep on adding these if statements for error handling again and again and again our program would look absolutely tedious so how can we fix this fortunately we do have a few pretty solid proposals so let's take a look at them right now let's first take a look at one of the very first winner proposals this proposal is all about adding chegg as a built-in function in this proposal the author points out that error handling consists of a three key part trigger handler in the binding rule the trigger is when the error return is not nil the handler is whatever instructions it will put between the curly brackets as long as the trigger condition is met the binding rule at least in the context of this proposal is about after in executing the instructions in the handler do we want to return the function or do we want to continue executing the following instructions with this proposal implemented the final product is going to look something like this there's a check built-in function will first it's again the function that originally returns there's a potential error and then it's again the handler with the instructions to handle the potential error that gets a return from this function now as you can tell with this proposal we no longer need to write all of these if it conditions and at the same time the footprint of this proposal is a pretty minimum all you need is it to add a check built-in function the second proposal i want to go over which improves the error handling in gold is the one that introduces two new keywords which are guard and must now let's say that you want to use the open function in the os package and now this function is going to return two things so one is what you're actually looking for and the other one is the error the potential error coming from this open function and the guard keyword is a synthetic sugar to return from a function when a function call returns an error so instead of having to check the error if the error is not new and then return the function that this this open instruction lives in we can use the guide a keyword instead the second keyword there's this proposal introduces is the master keyword which is a sentence sugar to panic instead when there's an error returned so instead of using the if statements plus the panic call we can just use it the must a keyword before the function in the call that can return the potential error now this proposal introduces a two new keyword which introduces more footprints to the language compared to the last proposal we looked at all right next we have this a particular proposal with the greatest level of sophistication compared to all the other ones that we've mentioned in today's video now as you can see this is a very well crafted proposal with many detailed sections but the just is it to introduce this new try built in the function now let's say that again you have this open function call in the os package that you want to execute and this open function will return to two things one is what you're actually trying to get and uh the second thing is the potential error that is open function returns instead of having to write the if statement you would just use this try built-in function instead to wrap around the function that you're trying to call now you might be thinking this seems hardly familiar with the first proposal that we just went through remember that in our first proposal here we also have this built-in function that takes in the function that actually returns the error as a parameter the difference is the first proposal actually requires us to pass in a handler in order to handle the error that there's a function potentially returns versus the try built-in function it will just return zero values are for the other results if any so we don't have to pass in additional handlers to handle the potential error that there's a function returns which helps keeping our code nice and pretty so what do you think of these proposals do you like any one of them or do you think that the way go currently does errol handling is perfectly fine let me know in the comment section down below don't forget to get your free golang cheat sheets at golangdojo.com also make sure to like and subscribe and i'll see you ninjas in the very next video [Music] you

Channel: Golang Dojo

Views: 24,913

Keywords: golang, learn golang, go lang, go language, golang tutorial, go programming, golang for beginners, golang 2022, error handling in go, error handling, go error handling, golang error handling, programming tutorial, go programming language tutorial, go programming tutorial, go programming language, programming, golang error tutorial, go error package, golang programming, golang basics, golang errors coding, tutorial golang, tutorial go, error, tutorial, go errors, tutorials

Id: tC3n2DH3kMo

Length: 8min 34sec (514 seconds)

Published: Thu May 19 2022