Proposal: consider adopting noodle.Handler and noodle.Middleware signature about goji

[elithrar]

Just to clarify my understanding of your package—where does a package user handle the error returned from the noodle.Handler signature? My concern here is that returning an error in a mixed environment (where not handlers may be context aware yet) means the error is ignored completely.

Goji's goji.Handler type allows this already just by implementing ServeHTTPC for your custom handler type - e.g.

type AppHandler func(context.Context, http.ResponseWriter, *http.Request) error

func (ah AppHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    ah.ServeHTTPC(context.TODO(), w, r)
}

// This provides compatibility with goji.Handler
func (ah AppHandler) ServeHTTPC(c context.Context, w http.ResponseWriter, r *http.Request) {
    err := ah(c, w, r)
    if err != nil {
        // ...
    }
    // Error isn't ignored implicitly, even if the package isn't context.Context aware yet.
}

Package users who don't want to write their own ServeHTTPx method can avoid that and just continue along with the way the standard library does it, or just add context.Context to their handlers and get a goji.Handler 'for free'.

[zenazn]

I don't really see the benefit of an error return here. It doesn't help with middleware, since we already have a mechanism for aborting the middleware chain (i.e., not calling the inner Handler). And global and chain-local error handling is not something I'm particularly interested in: rendering errors into HTTP responses is application-specific and there's no benefit of having framework-level support for it.

While I think many applications would benefit from having centralized error handling, I don't think it's Goji's job to offer this abstraction, since Goji can't do it better than your application can.

[andviro]

@elithrar,
I've had some deliberation re including vs not including error return into noodle middleware. I think that error return fits well into service/resource pattern roughly outlined as follows:

type FooResource struct {}
func (res *FooResource) HandleErrors(next noodle.Handler) noodle.Handler {
    return func(c context.Context, w http.ResponseWriter, r *http.Request) error {
        switch next(c, w, r) {
        case SomeError:
            // handle one kind of error
            return nil
        default:
            // pass errors to central handler
            return err
        }
    }
}

func GlobalHandleErrors(next noodle.Handler) noodle.Handler {
    // similar here
}

foo := FooResource{}
r := NewAbstractRouter()
r.Use(GlobalHandleErrors)

fooGroup := r.Group("/foo")
fooGroup.Use(foo.HandleErrors)
fooGroup.GET("/", foo.Index) // foo.Index is a noodle.Handler

This is from application point of view. From handler POV error return allows quick and clean way to abort execution. Consider this pseudo-handler:

func (res *FooResource)Index(c context.Context, w http.ResponseWriter, r *http.Request) error {
    Res, err := SomePotentiallyFatalOperation()
    if err != nil {
        return err // just return an error and forget about it
    }
    // use Res
}

Another way would be to signal error to some external framework-specific function, like it's done in Gin:

func (res *FooResource)Index(c *gin.Context) {
    Res, err := SomePotentiallyFatalOperation()
    if err != nil {
        c.Error(err)
        return // this return is easy to omit in complex handler
    }
    ...
}

But if you see carefully, error signalling and handler flow are separate here. I've sometimes forgot to put return after c.Error() and handler didn't stop where it should have. It's maybe only my problem, but I think that such mistake is not easy to see right away in complex handler code.

@zenazn, I see your point. From the abstract router POV error is not really nessessary, because HTTP requests are routed, handlers fired and it's not a router's business to care about their results. Then there's possible upcoming HandleHTTPC to consider. Well, I think that I'm gonna make noodle.Handler implement goji's Handler interface, so that error return will not stick out in signature. This will maintain compatibility and benefit all of us in the long run.

[zenazn]

I've sometimes forgot to put return after c.Error() and handler didn't stop where it should have

Ha. We've all done this :)

And point taken. I've personally had good luck with a structure similar to what @elithrar is suggesting (i.e., creating a no-error to error adapter), but I'll be the first to admit that I don't think I've got this figured out particularly well.