我一直在使用 golang 来自动化一些部署过程，我不得不使用 exec 包来调用一些 bash 脚本。

我使用了 exec.Command("/home/rodrigo/my-deploy.sh").CombinedOutput() 我看到了他的实现

func (c *Cmd) CombinedOutput() ([]byte, error) {
    if c.Stdout != nil {
        return nil, errors.New("exec: Stdout already set")
    }
    if c.Stderr != nil {
        return nil, errors.New("exec: Stderr already set")
    }
    var b bytes.Buffer
    c.Stdout = &b
    c.Stderr = &b
    err := c.Run()
    return b.Bytes(), err
}

我意识到在使用 CombinedOutput() 时您不能分配 c.Stdout 我认为这没问题，但通知 api 调用者的方式不正确.

CombinedOutput() 当你以错误的方式使用它时返回一个错误，所以如果你打算使用 CombinedOutput() 那么你不应该分配 c.Stderr 或 c.Stdout 之前，如果你这样做，那么你将收到一个错误。

但这个错误不是因为你的脚本抛出错误，而是因为你使用了错误的 api，在那种情况下我相信你应该得到一个 panic 因为不应该使用错误的 api处理(我认为)。

我来自 Java World，当您以错误的方式使用某些方法时，您会收到一个 RuntimeException，例如。

public void run(Job job) throws NotCompletedJob {
    if (job.getId() != null) {
        throw new IllegalArgumentException("This job should not have id");
    }
    job.setId(calculateId());
    job.run();
}

有了这个签名，我可以知道我用一个有 id 的 Job 调用 run(obj); 是错误的，事实上我可以区分我的脚本是有错误还是我' m 以错误的方式使用 api。

NotCompletedJob 是一个已检查的异常，所以我必须处理它，但 IllegalArgumentException 不是，所以我可以随时得到它。捕获 IllegalArgumentException 或任何其他 RuntimeException 并不总是被认为是一种好的做法，因为它们表明从程序员的角度来看你有一个错误，并且它不是像 NotCompletedJob。

话虽如此，我如何区分当前 CombinedOutput() 实现中的编程错误(例如错误的 api 用法)和预期错误(脚本未正常完成)？

为了澄清我的担忧，我并不是说 CombinedOuput 的当前实现是错误的，但我不明白调用者如何区分是正在执行的命令错误还是由他的错误引起的错误api 用法。

我认为最好的方法是在调用者以错误的方式使用 api 时 panic ，就像调用者将 nil 引用传递给期望非 nil 引用的函数(实际上这是当前的行为)。

最佳答案

I come from Java World and when you are using some method in the wrong way then you receive an RuntimeException.

您现在处于围棋世界中。因此，该论点是无效的。放弃 Java。

The Go Programming Language Specification

Handling panics

Two built-in functions, panic and recover, assist in reporting and handling run-time panics and program-defined error conditions.

func panic(interface{}) 
func recover() interface{}

While executing a function F, an explicit call to panic or a run-time panic terminates the execution of F. Any functions deferred by F are then executed as usual. Next, any deferred functions run by F's caller are run, and so on up to any deferred by the top-level function in the executing goroutine. At that point, the program is terminated and the error condition is reported, including the value of the argument to panic. This termination sequence is called panicking.

The Go Blog

Defer, Panic, and Recover

The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values.

Go Code Review Comments

This page collects common comments made during reviews of Go code, so that a single detailed explanation can be referred to by shorthands. This is a laundry list of common mistakes, not a style guide.

Don't Panic

See https://golang.org/doc/effective_go.html#errors. Don't use panic for normal error handling. Use error and multiple return values.

Effective Go

Errors

The usual way to report an error to a caller is to return an error as an extra return value.

您的 Go 服务器程序正在同时处理 100,000 个客户端。如果发生错误，报告并处理；始终检查错误。不要让所有 100,000 个客户端因 panic 而崩溃。 Go 包不应该 panic。

阅读 Go 文档和 Go 标准库代码。

关于go - 在 golang 中处理逻辑错误与编程错误的惯用方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50762775/