Closed klihub closed 4 months ago
I think we need to bump our go version to at least 1.19.
Yeah, I figured too.
Are our clients using go >= 1.21 to build their applications?
For completeness, I recently did something similar in one of our projects to enable errors.Join
in go1.17: https://github.com/NVIDIA/nvidia-container-toolkit/pull/337
The use of
errors.Join
can clean this up even further since it's never required to store a slice of errors.
If you don't care about how the topology of the final set of stored errors look like, but (for some reason) I prefer to keep errors 'at the same level' in the same slice (of joinErrors) and only 'cascading result of errors' (errors caused by other errors) nested the way it would be if we used the code you suggested. See my other related comment...
The use of
errors.Join
can clean this up even further since it's never required to store a slice of errors.If you don't care about how the topology of the final set of stored errors look like, but (for some reason) I prefer to keep errors 'at the same level' in the same slice (of joinErrors) and only 'cascading result of errors' (errors caused by other errors) nested the way it would be if we used the code you suggested. See my other related comment...
OK. That's a fair point. I was not considering this aspect.
Migrate from our internal multierror implementation to using error slices and stock errors.Join().