Golang 2错误处理草案设计探讨

Golang 2错误处理草案设计探讨

原始问题 我觉得我误解了[错误处理草案设计概述](https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md)的这一部分。

文中指出"check/handle组合允许在自身不返回错误的函数中使用"，但文档中的第一个示例（以及完整草案设计文档中的更多示例）却展示了一个返回错误的函数（CopyFile()）。我遗漏或误读了什么？

编辑：显然我睡眠不足 😊 这意味着该组合甚至可以在不返回错误的函数中使用，也可以在返回错误的函数中使用。

无论如何，我对错误处理提案感到非常兴奋；它似乎能在总体上减少代码冗余，同时仍鼓励正确处理错误。


更多关于Golang 2错误处理草案设计探讨的实战教程也可以访问 https://www.itying.com/category-94-b0.html

6 回复

同样非常重要的是要注意，这些改动是针对Go 2版本的。虽然官方表示会尽可能保持向后兼容性，但也明确说明从v1到v2版本将会引入所有重大或破坏兼容性的变更。

更多关于Golang 2错误处理草案设计探讨的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


我认为我们在很大程度上意见一致。我的理解是，错误处理（就像泛型一样）在潜在改进方面已经获得了足够的关注，团队现在认为可能有充分的理由这样做。据我所知，发布这些草案的目的正是你所建议的：公开讨论并寻求相关社区对这些提案的反馈。这些草案不是强制要求或功能公告。

Lazer:

嘿，我对错误处理提案感到非常兴奋；看起来它通常会让代码变得不那么冗长，同时仍然鼓励进行适当的处理

这真的会让代码变得不那么冗长吗？我希望如此，但我不认为会有太大改变。对于每个错误，你仍然需要做一些特定的处理。

更重要的是，它会让语法与 C/Java/Python 不同——因此学习起来会稍微困难一些，所以学习 Go 的年轻人会减少。

另外，它解决了什么问题？有人抱怨过 Go 因为错误处理而太冗长吗——我不这么认为。

我确信支持者看到了其中的好处，但我确实有一点疑虑。

另外，它解决了什么问题？

这在设计草案中已有说明，请参阅此处的"问题概述"部分：错误处理——问题概述

有人抱怨过 Go 因为错误处理而过于冗长吗——我不这么认为。

是的，我多次看到人们抱怨错误处理并提出改进建议。设计团队显然也注意到了这一点，他们在设计草案页面的"背景"部分列举了相关案例（他们提到"长期以来已有许多改进 Go 错误处理的提案"：错误处理——设计草案）

请不要误解——我目前很喜欢 Go 的错误处理方式，但我确实认为有改进空间。这份设计草案提出了一些我十分期待的改进方案。最妙的是，这些错误处理特性应该完全向后兼容，因此没有人会被强制使用它们（至少语言本身不会强制要求）

Lazer：

别误会——我目前很喜欢 Go 的错误处理机制，但也确实看到了改进空间。这份设计草案提出了一些我欣赏的改进方案。最棒的是，错误处理功能应该完全向后兼容，因此没有人会被强制使用它们（至少语言层面不会）

Go 语言的优势之一在于它（曾经）很少改变，且每次改变都有充分理由。如果像 Java 那样每年都有变化（新增功能），会让人望而却步。

我理解 Java（仅举例说明，其他语言也大同小异）的情况：企业中有个部门必须每年汇报工作成果，这就是为什么每年都有新增变化的额外动力。

Go 不应陷入这种陷阱。

此外，Go 还面临另一个问题：变更和决策应当公开民主。不应由精英团体决定其未来，而应由广大社区运用集体智慧、满足集体需求——任何变更都应由集体决定。

因此我认为，任何新功能都必须存在真实迫切的需求，并且有大量社区成员积极要求，这一点至关重要。

在Go 2错误处理草案中，check/handle机制的设计确实允许在不返回错误的函数中使用，这体现了其灵活性。你的理解是正确的：该组合不仅适用于返回错误的函数，也适用于那些本身不返回错误但需要处理内部操作错误的场景。

关键点解析：

  • check：自动检查错误并传播，可替代传统的if err != nil模式。
  • handle：定义错误处理逻辑，能够捕获特定错误类型或执行清理操作。

示例代码说明：

以下示例展示了一个不返回错误的函数 ProcessData()，它内部调用了可能失败的操作，通过check/handle处理错误：

package main

import "fmt"

// 假设的数据库操作，返回错误
func dbQuery() error {
    return fmt.Errorf("connection failed")
}

// 不返回错误的函数，使用 check/handle
func ProcessData() {
    handle err {
        fmt.Printf("Error handled: %v\n", err)
        // 执行清理或日志记录
        return // 终止函数执行
    }
    
    // check 自动检查 dbQuery 的错误
    check dbQuery()
    
    fmt.Println("Data processed successfully") // 不会执行
}

func main() {
    ProcessData()
    // 输出: Error handled: connection failed
}

解释：

  • ProcessData 函数没有返回错误类型，但通过 check dbQuery() 自动检查并传播错误到 handle 块。
  • 当 dbQuery 返回错误时，控制流跳转到 handle 块，执行错误处理逻辑，函数提前终止。

这种设计减少了冗余的错误检查代码，同时保持了错误处理的明确性。对于返回错误的函数，check 会自动将错误返回给调用方，与现有模式兼容。草案通过统一机制覆盖了多种用例，这正是其优势所在。

回到顶部