如何将Go中间件模式与错误返回请求处理程序结合在一起？

一尘不染

如何将Go中间件模式与错误返回请求处理程序结合在一起？

我熟悉这样的Go中间件模式：

// Pattern for writing HTTP middleware.
func middlewareHandler(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Our middleware logic goes here before executing application handler.
        next.ServeHTTP(w, r)
        // Our middleware logic goes here after executing application handler.
    })
}

例如，如果我有一个loggingHandler：

func loggingHandler(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Before executing the handler.
        start := time.Now()
        log.Printf("Strated %s %s", r.Method, r.URL.Path)
        next.ServeHTTP(w, r)
        // After executing the handler.
        log.Printf("Completed %s in %v", r.URL.Path, time.Since(start))
    })
}

和一个简单的handleFunc：

func handleFunc(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte(`Hello World!`))
}

我可以这样合并它们：

http.Handle("/", loggingHandler(http.HandlerFunc(handleFunc)))
log.Fatal(http.ListenAndServe(":8080", nil))

很好

但是我喜欢处理程序能够像正常函数一样返回错误的想法。这使错误处理变得容易得多，因为如果有错误，我可以只返回错误，或者在函数末尾仅返回nil。

我这样做是这样的：

type errorHandler func(http.ResponseWriter, *http.Request) error

func (f errorHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    err := f(w, r)
    if err != nil {
        // log.Println(err)
        fmt.Println(err)
        os.Exit(1)
    }
}

func errorHandle(w http.ResponseWriter, r *http.Request) error {
    w.Write([]byte(`Hello World from errorHandle!`))
    return nil
}

然后像这样包装它来使用它：

http.Handle("/", errorHandler(errorHandle))

我可以使这两种模式分别工作，但是我不知道如何将它们组合在一起。我喜欢我能够将中间件与Alice之类的库链接在一起。但是如果他们也可以返回错误，那就太好了。我有办法实现这一目标吗？

阅读 196

2020-07-02

共1个答案

一尘不染

我也喜欢这种HandlerFuncs返回错误的模式，它更加整洁，您只需编写一次错误处理程序即可。只需将中间件与包含的处理程序分开考虑，就不需要中间件传递错误。中间件就像一条链，依次执行每个中间件，然后最后一个中间件是知道您的处理程序签名并适当处理错误的中间件。

因此，以最简单的形式，使中间件保持完全相同，但最后插入一个具有这种形式的中间件（并且不执行另一种中间件，而是执行特殊的HandlerFunc）：

// Use this special type for your handler funcs
type MyHandlerFunc func(w http.ResponseWriter, r *http.Request) error


// Pattern for endpoint on middleware chain, not takes a diff signature.
func errorHandler(h MyHandlerFunc) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
       // Execute the final handler, and deal with errors
        err := h(w, r)
        if err != nil {
            // Deal with error here, show user error template, log etc
        }
    })
}

…

然后像这样包装您的函数：

moreMiddleware(myMiddleWare(errorHandler(myhandleFuncReturningError)))

这意味着这个特殊的错误中间件只能包装您的特殊功能签名，并且位于链的末尾，但这很好。另外，我会考虑将这种行为包装在您自己的多路复用器中，以使其更简单并避免传递错误处理程序，并让您更轻松地构建中间件链，而不必在路由设置中进行难看的包装。

我认为，如果您使用的是路由器库，则可能需要对此模式的显式支持。您可以在此路由器中以修改后的形式查看此示例的运行方式，该示例完全使用您要使用的签名，但是可以处理中间件链并无需手动包装即可执行：

https://github.com/fragmenta/mux/blob/master/mux.go

2020-07-02