在web应用程序中使用panics

Question

func Handler(body func(http.ResponseWriter, *http.Request)) func(http.ResponseWriter, *http.Request) {
    return func(responseWriter http.ResponseWriter, request *http.Request) {
        defer recoverIfPanic(responseWriter, request)
        body(responseWriter, request)
    }
}

func recoverIfPanic(responseWriter http.ResponseWriter, request *http.Request) {
    reason := recover()
    if reason == nil {
        return
    }
    // log and return http error
}

func PanicIf(err error, httpStatus int, description string) {
    if error != nil {
        panic(MyPanicStruct{err: err, httpStatus: httpStatus, description: description})
    }
}

result, err := SomeApi(...)
PanicIf(err, http.StatusInternalServerError, "SomeApi")

在99%的情况下，当SQL server返回意外错误或文件系统中缺少文件时，我不能做任何合理的事情，我只想记录这种情况并将错误返回给用户。所以我看不出有什么理由应该返回“err”手动展开堆栈，实际上我会丢失stacktrace和上下文，并且更难找到错误的原因。

有没有什么我错过了，所以这种方法不会很好地工作？似乎大多数Go文章都建议不要使用panic/recover，但我不明白为什么。它看起来非常像Java（和类似语言）中的旧抛接机制，并且非常适合web应用程序。

Answer 1

有没有什么我错过了，所以这种方法不会很好地工作？

这是今天讨论的（！）2014年11月4日，戴夫·切尼在“错误处理与异常还原”中

C++异常仍然像三十年前一样难以安全使用。当调用堆栈的任何部分在没有警告的情况下爆炸时，难怪许多C++商店要求不使用异常。

throw new SomeoneElsesProblem();

panic("inconceivable")

使用err的其他方法在官方wiki页面“错误处理和执行”中进行了讨论。

也就是说，文章“defer、Panic和recover”确实提到了Panic的一个实际情况(JSON包，(d*decodestate)unmarshal方法），并添加：

Go库中的约定是，即使包在内部使用panic，其外部API仍然会显示显式的错误返回值。