gin
gin copied to clipboard
Need a gracefull way to set Error instead of c.Error?
- 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.
It seems to me that this is an implementation detail, not something that merits a framework change.
It seems to me that this is an implementation detail, not something that merits a framework change.
c.Error
is 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.
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.
my linter is also unstatisfy with the return error.
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.
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
@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
_ = c.Error(err)
@inv2004 @sleagon
@bestgopher
Yes, but it looks more like workaround because c.AbortWithStatusJSON
does not require the W/O