Use pointer receiver for type-defined errors #161
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The old code use value receiver for type-defined errors like
ErrTaken
, it makesErrTaken
and*ErrTaken
are both valid errors.When I saw the the value receiver, I thought the way to check errrors should be
Unfortunately, it didn't work. Since the code returned
&ErrTaken
.redsync/mutex.go
Line 327 in b292c9f
And I also see mix-use of the two types in the repo, the test code uses
RedisError
as an error:redsync/error_test.go
Lines 19 to 22 in b292c9f
But here it uses
*RedisError
as an error:redsync/mutex.go
Line 327 in b292c9f
So, I believe it's a good idea to use pointer receiver for type-defined errors, just like most errors in golang standard packages like
url.Error
andos.PathError
. It doesn't break anything, since the right ways to handle such errors are the same before or after this PR: