• go version: 1.12.6
  • gin version (or commit ref): 1.4.0
  • operating system: Mac osx

Description

We are use golangci as our lint tool, errchek is one of the basic rule. We use c.Error to append errors happened in the controller and there is no need to handle return value of c.Error. Every time we use c.Error, we need add a comment to disable lint for that line.

router.GET("/:name", func(c *gin.Context) {
                // do sth
        c.Error(err)  // nolint: errcheck
})

What's more, we do not want our application panic when err is nil.

Comment From: austinheap

It seems to me that this is an implementation detail, not something that merits a framework change.

Comment From: sleagon

It seems to me that this is an implementation detail, not something that merits a framework change.

c.Erroris not quite friendly to developers, add a simple method will solve it. Otherwise, we need add a utils.WithError to do this kind of stuff.

Comment From: llianc62

I'm also frustrated with c.Error. It against gonlangci-lint. Is possible to erase return *Error ? What I am using now is that set my own key "error" for each error handling, when an error occurred. c.Set("error", err). Then in my error handler middleware to handle it. I just think that gin provided an Errors as a list to concentrate handle error, why we cannot use it well.

Comment From: coolyrat

my linter is also unstatisfy with the return error.

Comment From: sleagon

feel free to close this, by the way, if anyone want to catch error and format the response especially doing I18N at the same time, here is a extremely simple and clean package to do this.

Comment From: inv2004

Any good solution for the issue?

c.Error(err) would be good if no linter warning, the only one which does not return *Error is AbortWithJSON

Comment From: inv2004

@bestgopher There is open PR for it. Can you please comment there? c.Error cannot return nil, that is why the function is not for error-check and it would be good to have smth like c.GraceError which does not return error like c.AbortWithStatusJSON does

Comment From: bestgopher

_ = c.Error(err) @inv2004 @sleagon

Comment From: inv2004

@bestgopher Yes, but it looks more like workaround because c.AbortWithStatusJSON does not require the W/O