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

Create a generic "nats" error #1172

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

Create a generic "nats" error #1172

wants to merge 1 commit into from

Conversation

sylr
Copy link
Contributor

@sylr sylr commented Dec 24, 2022

This allows to catch all NATS error client side with:

if errors.Is(err, nats.ErrNats) {
    ...
}

Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
@wallyqs
Copy link
Member

wallyqs commented Dec 24, 2022

Thanks for the contribution, there some cleanup that we need to do for the errors to better take advantage of error wrapping and the error interface. My opinion here is that it should be a nats.Error interface type somewhat like the net.Error type (minus Temporary()) kind of like this:

	ErrConnectionClosed Error = &natsErr{msg: "connection closed"}
	ErrDrainTimeout     Error = &natsErr{msg: "draining connection timed out", timeout: true}
	ErrTimeout          Error = &natsErr{msg: "timeout", timeout: true}

@sylr
Copy link
Contributor Author

sylr commented Dec 24, 2022

go1.20 comes with multi error wrapping so you could combine multiple errors such as ErrNats and ErrTimeout in subsequent and relevant errors.

@wallyqs
Copy link
Member

wallyqs commented Dec 24, 2022

@sylr yes! I'm looking forward to that change and how we could adopt, btw what do you think is the main use case to be able to match against all errors from the package? Seems would be mostly for debugging or logging since the generic error does not give enough info about how to handle the error?

@sylr
Copy link
Contributor Author

sylr commented Dec 24, 2022

It's pretty hard to know which errors could be returned by nats sdk's methods so a generic catchable error can be used to implement a generic fallback if nats errors. In the end you could end up implementing more specific error handling based on the full error but I think a generic one is a good way to start.

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.

None yet

2 participants