20210221error似乎不具备太多功能性（2） - ziyouzy/2021blog GitHub Wiki

先看下fsnotify的范例：

https://github.com/fsnotify/fsnotify

main函数：

package main

func main() {
watcher, err := fsnotify.NewWatcher()
if err != nil {
	log.Fatal(err)
}
defer watcher.Close()

done := make(chan bool)
go func() {
	for {
		select {
		case event, ok := <-watcher.Events:
			if !ok {
				return
			}
			log.Println("event:", event)
			if event.Op&fsnotify.Write == fsnotify.Write {
				log.Println("modified file:", event.Name)
			}
		case err, ok := <-watcher.Errors:
			if !ok {
				return
			}
			log.Println("error:", err)
		}
	}
}()

err = watcher.Add("/tmp/foo")
if err != nil {
	log.Fatal(err)
}
<-done
}

可以看到从Errors管道中拿出要给err后，只是进行了简单的日志打印工作，而具有逻辑性或触发性的操作则全部留给了Events管道的event

其实应该是这样的概念：
首先，错误和异常时不同的，异常是十分严重的问题，不是程序该存在的一部分，而错误则不是，错误是程序应该存在的一部分，比如心跳包的timeout事件
**其次，由于错误只能返回一个“简短的说明”因此，无论是设计哪个程序，哪种应用场景，报错的那一层出来发现并返回错误这个职责外，也应该负责处理错误，而该把处理错误这件事随着error对象一起丢给上层。
而与之对应的event（signal）则相反，他之所以返回上层的目的就是告诉上层该做一些其他的事情了。

具体对比如下：

error： error所在层出错，error所在层处理，error所在层发送error信息给上层；上层接收报错信息，上层不负责解决问题
event(signal): event所在层无问题，event所在层无需要处理的问题，event所在层发送event信息给上层；上层收到evnent信息，上层负责解决问题