Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use pointer receiver for type-defined errors #161

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wolfogre
Copy link

@wolfogre wolfogre commented Aug 22, 2024

The old code use value receiver for type-defined errors like ErrTaken, it makes ErrTaken and *ErrTaken are both valid errors.

When I saw the the value receiver, I thought the way to check errrors should be

var target redsync.ErrTaken
if errors.As(err, &target) {
	// ...
}

Unfortunately, it didn't work. Since the code returned &ErrTaken.

err = multierror.Append(err, &RedisError{Node: r.node, Err: r.err})


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

err := RedisError{
Node: 0,
Err: v,
}

But here it uses *RedisError as an error:

err = multierror.Append(err, &RedisError{Node: r.node, Err: r.err})


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 and os.PathError. It doesn't break anything, since the right ways to handle such errors are the same before or after this PR:

var target *redsync.ErrTaken
if errors.As(err, &target) {
	// ...
}

Copy link

stale bot commented Oct 21, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added wontfix and removed wontfix labels Oct 21, 2024
@wolfogre
Copy link
Author

Kindly ping ~

Copy link

stale bot commented Dec 22, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Dec 22, 2024
@wolfogre
Copy link
Author

Kindly ping ~

@stale stale bot removed the wontfix label Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant