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

Convert []error to use multi errors available in 1.20 #117

Open
thrawn01 opened this issue May 17, 2023 · 5 comments
Open

Convert []error to use multi errors available in 1.20 #117

thrawn01 opened this issue May 17, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@thrawn01
Copy link
Contributor

Thanks for the wonderful library! After converting from a different library, I have a single suggestion!

The current code base returns multiple errors which is inconvenient to use if multiple errors are not useful to the caller. We could instead create an error that implements the Unwrap() []error method which can be used to retrieve multiple errors.

// Existing signature
RenderAndReload() ([]byte, Document, *DocumentModel[v3high.Document], []error)
// Would become
RenderAndReload() ([]byte, Document, *DocumentModel[v3high.Document], error)

Example implementation

type MultiError struct {
	errs []error
}

func (e *MultiError) Error() string {
	var b []byte
	for i, err := range e.errs {
		if i > 0 {
			b = append(b, '\n')
		}
		b = append(b, err.Error()...)
	}
	return string(b)
}

func (e *MultiError) Unwrap() []error {
	return e.errs
}

The conversion would be easy, but would break the compatibility. As such it should probably wait for a v1 or v2 release.

See https://pkg.go.dev/errors#Join

@daveshanley
Copy link
Member

Ah yes, I thought the same thing when I saw the release notes for 1.20.

Yes this is a good idea, adding it to the backlog.

@n0rig
Copy link

n0rig commented Feb 18, 2024

@daveshanley is this still the approach you want to be followed? If so, I can work on this.

@jxsl13
Copy link

jxsl13 commented Feb 18, 2024

I'd suggest just using errors.Join and return a single error.

@daveshanley
Copy link
Member

I would avoid working on this until the library is ready for 1.0, it's a major breaking change to the top level of the library in terms of signature. It's a small change with big consequences.

@stevenh
Copy link

stevenh commented May 24, 2024

@daveshanley I would suggest doing it ASAP as that will result in less people having to alter their code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants