自己写的 go 代码就是由一堆的 if 搭起来的

• 資深大佬 : togou

  主要有的东西感觉根本不会 err 的你就把他 _ 掉算了

• 資深大佬 : THESDZ

  是不是过度封装了?
  导致需要判断返回的地方太多了?

• 資深大佬 : lepig

  贴段代码看看

• 資深大佬 : sunorg

  业务逻辑不就是这样？？

• 資深大佬 : SuperMild

  if err !=nil 太多是 Go 的缺点，你可以看看剔除这个之后，if 还多不多。

• 資深大佬 : SuperMild

  更正：不是缺点，是特点。

• 資深大佬 : chenqh

  有个问题，golang 加个默认值有那么困难吗？

• 資深大佬 : wysnylc

  @SuperMild #6 是特色,是进步!

• 資深大佬 : lewis89

  如何看待百度无人车有 3 万个 if

• 資深大佬 : DeWhite

  if err 我个人觉得是一个好东西，我可以通过返回值 找到写报错的地方。

• 資深大佬 : jin7

  换语言 逃….

• 資深大佬 : jinliming2

  我觉得：Go 里的 if err != nil 判断是否出错，表明这里确实有可能出错，那么不论是什么编程语言，都是有可能出错的。
  比如写个除法函数，返回商和余数，但如果除数参数提供了 0，那么结果就是应该出错（不考虑返回无穷之类的情况）。
  在其他语言里，这叫“异常”，他们几乎都有 try-catch 语法，来捕获错误，比如：
  “`
  try {
  可能出错的函数 A();
  可能出错的函数 B();
  可能出错的函数 C();
  } catch (错误 A) {
  } catch (错误 B) {
  } catch (错误 C) {
  } finally {
  }
  “`
  在 Go 里面，实际上也有类似的写法：
  “`
  defer func () {
  if err := recover(); err != nil {
  // 判读 err 的类型，处理不同错误
  }
  // finally
  }()
  可能出错的函数 A()
  可能出错的函数 B()
  可能出错的函数 C()
  “`
  这样写是不是就有点类似了？
  但是不管是 try-catch 还是 panic-recover，他们的问题都是：抛出错误，在某个位置集中捕获。这样在代码层面你就不知道错误具体是在哪里抛出来的了，只能在运行时打堆栈，相同类型的错误也就只能是统一的处理方法。

  而 Go 语言的一般风格是：错误在哪里抛出，就在哪里处理掉，这样对错误的处理会比较明确。

  比如在一个函数里有两个除法运算，除数都有可能为 0 。那么 try-catch 就只能在捕获到错误时打一个除数为 0 的日志，而 Go 的风格则可以报第一步除数为 0 或是第二步除数为 0 。

  当然，try-catch 也可以写成 一行语句一个捕获的形式，那样的话比 if err != nil 更恐怖，而且还有变量块级作用域的问题。

• 資深大佬 : Mohanson

  只要胆子大, 贞子放产假

  https://github.com/mohanson/doa

  刚写的库, 就等 go1.17 上泛型可以带返回值类型了…

• 資深大佬 : Mohanson

  不过事实上我已经用 go2go 分支编译过, 换成泛型写法爽歪歪~

  现在自己写的几个库都在等泛型重写, 没泛型可真的要命

• 資深大佬 : leavic

  if err 我觉得根本是 golang 自己的坑

• 資深大佬 : Mac

  不是还有人用一堆 if 做游戏的嘛

• 資深大佬 : loolac

  @jinliming2 追溯错误来源一般都堆栈轨迹的吧，try-catch 可以根据错误处理继续后面的逻辑，比如错误可以导致返回结果的变更，但是 panic-recover 就很难做到了，golang 函数调用基本上都是传值，defer 函数中要改变返回内容，必须使用指针，而且封装逻辑也必须使用闭包函数，出错前后的代码逻辑和可复用部分的代码必须使用闭包函数封装，写出来的代码很“反”。
• 資深大佬 : hallDrawnel

  如果函数会出错，本来就应该处理错误呀。我觉得 if err != nil 虽然繁琐，但是从语法上强迫人处理错误是一件好事情。

• 資深大佬 : phithon

  学几个设计模式，多用些接口，可能会好点

• 資深大佬 : xyxy

  诶 是因为新手，我新写 golang 也是这样的

• 資深大佬 : woahishui

  @jinliming2 这个缺点没有必要这么解释，程序的异常判断是正常的，但是在哪一层用户进行捕获，进行处理是用户自己的事情，所以这种写法就是因为用户不知道怎么去抛出异常，怎么在统一位置处理异常，才有的疑问

• 資深大佬 : woahishui

  或许主是对如何抛出异常，如何优雅的统一处理异常不知道在 golang 怎么处理才有的这种感觉

• 資深大佬 : ArJun

  其实看情况的，有些 err 可以直接_替换，没必要写那么多判断 err

• 資深大佬 : ylsc633

  我情愿多写点 if err != nil

  对于排错真的很友好..

  对于一些十分有把握不会出现的 我直接 _

• 資深大佬 : chengxiao

  别想太多 写就是了
  到后面你会发现 如果没 error 返回
  更让人害怕

• 資深大佬 : a719031256

  这种写法其实挺好的，出了问题也容易找，最怕拼了命的封装写法，那个找问题就像从一堆垃圾中找一颗针

• 資深大佬 : LANB0

  @togou 感觉不会 err 的地方，到后面一定会遇到 err 。写代码不要想当然，不然猿类早消灭 bug 了

• 資深大佬 : stirlingx

  程序员的工作量不在于多写几个 if，而是排查 bug 。go 这种方式对找 bug 真的方便，可以省很多时间

• 資深大佬 : BoarBoar

  等你写多了 你就会发现 if err ！=nil 还是那么多

• 資深大佬 : nguoidiqua

  不用 if 就会别的，除非不写程序，我反正 try catch if 什么的都可以接受。

• 資深大佬 : kuro1

  鲁棒性极佳

• 資深大佬 : dream4ever

  @Mohanson 就冲你这么大胆，我也要毫不留情地给你点个赞

• 資深大佬 : wzw

  @Mohanson 还要很久吧

• 資深大佬 : newtype0092

  @jinlimling2 看了你的对比，假如造一辆汽车，一般团队在关键结构用高强度材料进行加固，go 是把所有地方都用高强度制造，不计成本的生产方式？

• 資深大佬 : raaaaaar

  提前 return，这样不会太臃肿，给 error 分层，多封装点接口。。。。然后你会发现还是那么多 if 。。

• 資深大佬 : sssooonnnggg

  相比之下 rust 的 result+?就香疯了

• 資深大佬 : taowen

  @Mohanson https://github.com/mohanson/doa 唯一正解

• 資深大佬 : qloog

  面向错误编程，今早处理错误，是很不错的一种方法。