2019-04-09从语言设计上，不使用try-catch而是用defer-recover有什么优势？c++和java作为先驱都使用try-catch，也比较清晰，为什么go作为新语言却要发明一个这样的新语法？有何设计上的考量？作者回复: 这是两种完全不同的异常处理机制。Go语言的异常处理机制是两层的，defer和recover可以处理意外的的异常，而error接口及相关体系处理可预期的异常。Go语言把不同种类的异常完全区别对待，我觉得这是一个进步。
另外，defer机制能够处理的远不止异常，还有很多资源回收的任务可以用到它。defer机制和goroutine机制一样，是一种很有效果的创新。
我认为defer机制正是建立在goroutine机制之上的。因为每个函数都有可能成为go函数，所以必须要把异常处理做到函数级别。可以看到，defer机制和error机制都是以函数为边界的。前者在函数级别上阻止会导致非正常控制流的意外异常外溢，而后者在函数级别上用正常的控制流向外传递可预期异常。
不要说什么先驱，什么旧例，世界在进步，技术更是在猛进。不要把思维固化在某门或某些编程语言上。每种能够流行起来的语言都会有自己独有的、已经验证的语法、风格和哲学。 4 36
2018-10-10defer其实是预调用，产生一个函数对象，压栈保存，函数退出时依次取出执行 17
2019-04-23我感觉还是go的这种设计好用，它会强迫开发者区别对待错误和异常，并做出不同的处理。相比try{}catch，我在开发中经常看到开发者把大段大段的代码或者整个处理写到try{}中，这本身就是对try{}catch的乱用作者回复: 是的，这是最主要好处。
7
2019-04-22如果defer中引发panic，那么在该段defer函数之前，需要另外一个defer来捕获该panic，并且代码中最后一个panic会被抛弃，由defer中的panic来成为最后的异常返回。作者回复: 嗯，是的，由于之前发生的 panic 已经被 recover 了，所以最终被抛出去的就应该是外层 defer 语句中的那个 panic。
6
2018-12-27感觉还是try{}catch这种异常处理好用 5
2019-02-25Go 语言会把它携带的defer函数及其参数值另行存储到一个队列中。
这个队列与该defer语句所属的函数是对应的，并且，它是先进后出（FILO）的，相当于一个栈
直接表达为 创建defer时“函数对象“压栈，panic触发时出栈调用 更容易理解吧展开 4
2019-05-14「延迟到什么时候呢？这要延迟到该语句所在的函数即将执行结束的那一刻，无论结束执行的原因是什么。」
以该节课中代码为例的话是要吃到main函数快结束时执行是吗？执行defer函数。作者回复: defer 函数的执行时刻是在直接包含它的那个函数即将执行完毕的时候，也可以理解为下一刻就要返回结果值（如果有的话）的时候。对于 main 函数直接包含的 defer 函数来说，也是如此。
2
2019-12-07试验了一下在 goroutine 里面 panic，其他的 goroutine（比如main）是 recover()不到的：
func main() {
fmt.Println("start")
defer func() {
if p := recover(); p != nil {
fmt.Println(p)
}
}()
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer func() {
wg.Done()
}()
panic(errors.New("panic in goroutine"))
}()
wg.Wait()
}展开作者回复: 当然。因为它们之间不是串行的关系，所以 panic 传播不到其他的 goroutine 那里。所以，每个 goroutine 都应该有自己的异常处理代码。我们可以设计一个整体的异常处理规则或体系，并在每个 goroutine 里都遵循它。
1
2018-12-17如果defer中引发panic，那么在该段defer函数之前，需要另外一个defer来捕获该panic，并且代码中最后一个panic会被抛弃，由defer中的panic来成为最后的异常返回。 1
2018-11-22请问下，按您上面说的，一个recover只能恢复所在的那个函数。那如果一个 函数中有一个goroutine函数 而这个goroutine函数触发了panic，那是只有他自己可以recover是吗，他的上级是无法recover内部的goroutine的painc是这样吗？ 1- 2018-11-22请问下，按您上面说的，一个recover只能恢复所在的那个函数。那如果一个 函数中有一个goroutine函数 而这个goroutine函数触发了panic，那是只有他自己可以recover是吗，他的上级是无法recover内部的goroutine的painc是这样吗？ 1
2018-10-24defer func(){.....1}()
defer func(){.....2}()
defer func(){.....3}()
panic("4")
我在goland里面分别选择 gc 和 gccgo编译
发现执行的顺序不同 一个是3421一个是 3214展开 1
2020-02-05作者想把概念给我们讲清楚，但是我总觉着看着费劲。为啥？因为作者太啰嗦了。比如：
defer函数调用的执行顺序与它们分别所属的defer语句的出现顺序（更严谨地说，是执行顺序）完全相反。
改成这样就简单多了：defer函数的调用顺序与其defer语句执行顺序相反。
还有：当一个函数即将结束执行时，其中的写在最下边的defer函数调用会最先执行，其次是写在它上边、与它的距离最近的那个defer函数调用，以此类推，最上边的defer函数调用会最后一个执行。
改成：当一个函数即将执行结束时，最下面的defer函数先执行，然后是倒数第二个，以此类推。- 2019-11-06老师，最近遇到一个defer的问题，想请教一下！
defer在声明的时候会把函数和它的参数求值后拷贝一份先入栈，如果这个参数是值，那么在真正执行的时候不会改变，如果这个参数是引用，那在真正执行前如果改变了它的话，最终defer执行时的参数应该是改变后的！但是切片这种引用类型的参数，为什么没办法改变呢，而如果是一个指针的话就会被改变？
希望能得到您的解答，谢谢了！！！作者回复: 切片的话，要看你是怎么变的。比如，由于追加元素等操作导致切片以及底层数组彻底换新，原切片就不变。这需要具体情况具体分析，你最好把代码贴上来。
2019-10-31iava世界里曾经try catch满天飞，现在还能看到不少这种代码，但逐渐大家认同了在去掉这种代码。
因为大部分catch住异常以后只是打个log再重新throw，这个交给框架代码在最外层catch住以后统一处理即可。非框架代码极少需要处理异常。
go世界里，err guard满天飞，但大部分的处理也是层层上传。但做不到不用，因为不像try那样去掉catch后会自动往上传递，不检查err的话就丢失了，所以这种代码去不掉。只能继续满天飞。
底层实现其实都是setjmp，主要的区别之一我认为是go设计者认为java异常的性能代价大。展开作者回复: Go 的 error 其实就是在用普通的控制流来处理异常。但是性能却可以有非常明显的提高。其实不管怎么弄都做不到“羊毛出在猪身上”。不管是让开发者自行处理，还是运行时系统自己控制，都会对程序的流畅度产生影响。这就是程序稳定性和程序流畅度（包括可读性、控制流和性能等）之间的trade off。
1
2019-07-27老师的demo非常经典 每一个看着都很带劲
2019-07-09是否可以这样理解，defer语句就是在析构的时候执行的。
2019-06-05打卡，这篇文章的评论都很赞啊
2019-05-20关于思考题，可以的。
大的控制流是这样的：
panic函数那一行执行完后马上结束当前函数；而defer函数被调用就是发生在当前函数结束后的立即。这些规则/顺序是不变的。
所以说，如果panic函数放在defer函数调用链上（某一个defer函数体中），只要后续defer函数有recover函数并处理了这个panic，那么恐慌就被处理了；同理，如果后续defer函数没有recover函数被放置，那么在依次运行完defer函数链上的函数后，panic会继续向函数栈上一级抛（如果是main就直接终止进程了）。展开
2019-01-22打卡