对于所有错误处理,将panlang错误代码替换为恐慌

时间:2017-03-09 15:31:46

标签: go

我们用go编写的中型应用程序。从所有代码行中,大约60%用于代码错误处理。像这样:

if err != nil {
   return err
}

过了一段时间,一遍又一遍地写这些行变得很烦人,我们现在正考虑用恐慌来替换所有错误代码。

我知道恐慌不应该像那样使用。

什么可能是潜在的陷阱,是否有人有过类似的经历?

2 个答案:

答案 0 :(得分:1)

主要的缺陷是广泛使用锤子来驱动螺钉。 恐慌是针对不可恢复/意外错误,错误返回值是针对可恢复/预期错误。

将“恐慌”改为“崩溃”,因为这在概念上是恐慌。你真的想编写一个应用程序按设计崩溃什么时候出现任何远程错误?这将是地球上最脆弱的应用,与容错的对立。

答案 1 :(得分:0)

由于所有评论都表明你可能正在报名参加灾难而且让我补充一点,无论是什么人来维护这段代码都会疯狂地试图弄清楚当事情出现问题时出现了什么问题。做正确的错误处理(即使那个人是你,它会困扰你)。

重复其他人所说的 - 问题是无法区分这两个

  • 一个可预测的&可能的可恢复状况
  • 也许是不可恢复的(需要退出应用程序或在更高级别处理 - 这可能来自您自己的应用程序的条件或某些第三方库,但正在迫使您退出正常的执行路径)

恐慌是为后者保留的。