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

return []error rather than error #3

Merged
merged 1 commit into from
Oct 29, 2024
Merged

Conversation

gregwebs
Copy link
Owner

Concurrent functions return multiple errors.
These are now returned only as either a channel or a slice.

This avoids a dependency on a 3rd party multi errors library. The standard library errors.Join is awkward to use because there is not a simple way to unwrap the errors.

We could use a custom multi error.
However, to make this convenient to use it should be returned as a pointer to the struct rather than an opaque error. But Go has a subtle design issue where
an interface can end up being non-nil when storing a pointer to a struct.

Returning []error still allows the caller to use errors.Join() if they don't care about iterating the individual errors.

The main issue is that someone may check != nil rather than len > 0 However, all the APIs are designed to return nil rather than a zero length slice.

Additionally, don't use the default recovery handler. Write more errors to the error channels.
Panic a few errors that shouldn't happen.

@gregwebs gregwebs force-pushed the concurrent-error-slice branch 3 times, most recently from 41574d9 to 5c96121 Compare October 29, 2024 13:59
Concurrent functions return multiple errors.
These are now returned only as either a channel or a slice.

This avoids a dependency on a 3rd party multi errors library.
The standard library errors.Join is awkward to use because
there is not a simple way to unwrap the errors.

We could use a custom multi error.
However, to make this convenient to use it should be returned as a
pointer to the struct rather than an opaque error.
But Go has a subtle design issue where
an interface can end up being non-nil when storing a pointer to a struct.

Returning []error still allows the caller to use errors.Join() if they don't
care about iterating the individual errors.

The main issue is that someone may check != nil rather than len > 0
However, all the APIs are designed to return nil rather than a zero
length slice.

Additionally, don't use the default recovery handler.
Write more errors to the error channels.
Panic a few errors that shouldn't happen.
@gregwebs gregwebs force-pushed the concurrent-error-slice branch from 5c96121 to 2cf6934 Compare October 29, 2024 14:02
@gregwebs gregwebs merged commit 7b7812c into main Oct 29, 2024
3 checks passed
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