Good video, but there is an essential detail about the defer statement that you omitted which can be a really awkward gotchya if you’re not aware of it. And that is a defer creates a closure over local state. Your defer statement must make sure that any state that it interacts with is fully present at the time of the defer statement. Eg, let’s say the first thing inside of a func is a var declaration of an uninitiatialised variable. Next there is a defer that interacts somehow with this state. After the defer there is some logic that updates this state. If you think that when the defer actually runs it will see the updated version of that state, you will be surprised to learn that the version of that state the defer sees is the uninitialised version. This was a shock to me when I first discovered it and took me quite a while to realise what was happening. This occurs because the defer is working on the closure version of the state and hence only sees the uninitialised version. Hope this helps anyone to not fall into this subtle trap.
This not always true, it depends on the defer declaration Test it with: func work() { var v string defer func() { fmt.Println("V in func's defer", v) }() v = "asd" fmt.Println("V in func", v) } Outputs: V in func: asd V in func's defer: asd BUT: func work() { var v string defer fmt.Println("V in func's defer", v) v = "asd" fmt.Println("V in func", v) } Will indeed output: V in func: asd V in func's defer:
