Panic Recovery in Go - Tutorial

hi everyone it's elliot from tutorialedge.net and in this video tutorial we're going to be looking at how we can recover from panics within our go applications now panics are something i very rarely use within my day-to-day goal application development most of the time catching an error from whatever i'm calling and then logging out to whatever logging system i've got in place and emitting metrics based on these error situations is most often the preferential route now panics are not meant to be comparable to how we use exceptions in other programming languages such as java or javascript or php they are instead a ditch mechanism that is built into the language that allows us to handle error cases that we aren't able to handle in a graceful fashion so when we call a panic it will do two things it will look through all of the deferred functions that we have within the function b panic occurs in and it will then terminate that function so any code below this panic will not be executed however any deferred functions that we run or have registered will be called so let's see this in action so print line i am a deferred function fmt print line end of main let's open up the terminal do go run main.go and you can see this in action so it calls panic in the go up the panic is called and then the deferred functions are then looped through and then the function itself is terminated so this line of code is unreachable if we didn't panic go run main.go you can see panic and the go up which is this line here you can see end of main is called and then you can see the deferred function is called after the execution or at the end of the execution of this main function go so let's have a look at another example now in this example we have a cascade effect when panic is called so in our main function we call silly susan silly susan calls panic in peter and panicking peter panicks as the name might suggest now this line of code is going to be unreachable when this panic is called panicking peter terminates and the call to panicking peter within silly susan is then treated as a panic itself so this line of code will not be executed and if we have any deferred functions within silly susan this these deferred functions will have been executed now in this case we don't have any deferred functions this will never be called and this will then be treated as a panic within our main function and we can see this by putting an additional print line end of main function let's open up the terminal a little bigger and let's to go run main.go and as you can see cascading panics it then calls silly susan silly susan calls panicking peter panicking peter is called it panics less is never executed we can see that this line of x of code is never executed and we can see the stack trace so we can effectively trace this through our application to see where the panic has started and where each line of code is effectively treated as a panic so line seven is treated as a panic and line 20 is treated as a panic again we can't see this printed out because this has been treated as a panic cool so why is this behavior important well let's imagine you have a rest api and the function or one of your endpoints panics and when it receives malformed data say and it's not handled correctly well the best case scenario is a user calls your api and it crashes once and then hopefully you've got multiple instances of your rest api behind a load balancer so no other clients are impacted now the worst case scenario some bad actor some hacker realizes that this is the case and whenever they call a particular endpoint with this malformed data they can effectively bring down all of the instances of your application now this is a disaster case for us if we are running an application in production the hacker could effectively continually hit our endpoints continually bringing down all of our instances and deny the usage of our apis to any other clients which is you know worst case possible scenario we're not serving our clients we're not making money and we're panicking ourselves trying to figure out how we can effectively fix this situation so how do we sort these hackers well we can build in recovery mechanisms into our applications using this deferred functionality so let's do the third func and let's do if r is equal to recover r does not equal nil we can then say fmt print line print line hackers have been thwarted swarted i hope that's how you spell that cool so let's dig in a little deeper and see what we've done here so we've defined a deferred function here that calls the built in recover function now this recover function will effectively stop the panicking sequence and restores normal execution to our application so when the panic is called this deferred function will be called the panicking sequence will be stopped we'll then print this out and then silly susan will no longer see this panicking peter call as a panic and it will continue execution as though nothing has happened let's see this in action so let's do go run main.go and as you can see we have no panic stack traces down within our terminal cascading panics has been called silly susan has called panicking peter has been called the hackers have been thwarted in our recovery function here and then silly susan has finished the execution and then our main function has also been able to execute successfully now it should be noted that you can place this recovery function further up the stack should you wish let's say we had it in silly susan now what would effectively happen here as panicking peter would be called or referred to as a panic or treated as a panic this line of code would never be executed however this function would still be executed and the panic would be recovered from so let's see this in action so go run main.go as you can see silly susan is called silly susan never gets to finish and hackers have been thwarted as still called as we've been able to recover and the main function that calls silly susan has been able to continue execution as though nothing has happened now finally let's have a look at this in a production system so i've lifted the recovery handler function from the gorilla max library and as you can see here this is a recovery handler that allows us to ensure the panics within our rest api in this particular example do not bring that rest api down what they do instead is if any of the endpoints panics for whatever reason it'll write header that the status is internal server error it'll then attempt to log the error and the rest of your application will not be impacted so if you're defining production ready rest apis make sure that you have some form of recovery handler in place and this will prevent your application from from being brought down by malicious actors cool so that's all we're going to cover in this video tutorial i hope you found it useful if you have please let me know in the comment section down below and as always please remember to like and subscribe to my channel for more programming content cheers

Channel: TutorialEdge

Views: 5,674

Keywords: programming, tutorials, coding tutorials, tutorialedge

Id: 9iHQbcWmqUY

Length: 8min 58sec (538 seconds)

Published: Sun May 15 2022