hi there Serdar Yegulalp here for infoworld at idg in this episode of smart go we're going to
explore the panic and recover keywords in go and where it makes sense to use them generally in go
error handling works by returning two values from functions the value the function is supposed to
supply and an error value if the error value is not nil that means something has gone wrong
for instance in this code here i use this pattern as i've just described in the get name function
it returns two things a string and an error value if the string matches a certain predefined value
and the error gets set otherwise it defaults to nil no error when we call that function we check
what it returns to make sure no error has been raised if there is an error we handle it somehow
now goto has another pattern that can be used for error handling panic and recover but they are not
substitutes for returning error values they're used for when a program enters an unexpected state
with no graceful way to recover from it and so you want to exit from the program and provide details
about where things went wrong let's take a look at our first code snippet and rework it to use panic
instead of conventional error handling when we encounter our error condition and use the
panic keyword the function we're in doesn't return an error value the entire program
stops what's more when it stops we get a stack trace that shows where the error took place
along with an error code you'll notice that i also use the defer keyword here in my last
video i showed how the defer function can be used to run some command or some other function just
before the function it's in exits defer is also called when you invoke panic as you'll notice from
the output in the stack trace here the deferred function runs first and then the panic message so
this is useful if you need to clean up resources or do other things while on the way out of a panic
now this here is the key distinction with the panic the fact that it produces a stack trace
and the fact that it also exits the program completely if we encounter a program that really
can't be handled gracefully we panic so that we can provide the developer with information
about the issue somebody else put it this way panic is for the developer error is for the user
to that end you really shouldn't use panic for situations where more conventional error handling
will work just fine in this example here i'm using conventional error handling for the string itself
but i'm also putting in a panic check for an exceptional situation that should never arise
we should never have input pointing to nil but if by some crazy possibility we do we want to know
about it and we want to generate a stack trace that indicates that it's the source of the problem
now finally panic can be used in conjunction with another keyword recover
recover lets us trap a panic invocation so that doesn't end up crashing the whole program
this is useful if for instance we want to trap panics that might be raised by other packages that
we don't have direct control over or if we want to gradually introduce more granular handling of
panics into our own code by placing them into the deferred blocks for functions recover is
only used in a deferred block since that's the only place that we can reliably trap a panic
so we use recover by calling it like so and then checking to see what it returns if it returns nil
that means no panic has been raised and so that we can perform whatever actions we would normally
do in this deferred section but if recover returns something other than nil then we can take action
with it in any case the panic itself has been suspended it's not going to take place anymore
again in general you should use panic and recover as sparingly as you can
the default idioms for error handling and go are to return error values and to check for
them in future versions of go we may introduce some new idioms for error handling and they may
work completely differently but right now all the existing go code out there is written this way
so it's worth knowing what's in wide use right now that's it for this episode if you liked it please
leave a comment below don't forget to subscribe to the idg tech talk channel on youtube and for
more smart go and for more dev serdar be sure to follow me on facebook youtube and infoworld.com