Skip to content

Conversation

@crozzy
Copy link

@crozzy crozzy commented Oct 9, 2023

It's hard to reason with errors when strconv.ParseUint fails as the returned error is untyped. This change introduces a new error that is returned if the int parsing fails.

@crozzy
Copy link
Author

crozzy commented Oct 9, 2023

I suppose you could also wrap the err returned with %w ie. fmt.Errorf("Error parsing version segment: %w", err), to allow to caller to discern why things failed. It's a weird one because it could also be validated in the regex I suppose but judging by the spec it's not technically an invalid semver.

Copy link
Member

@mattfarina mattfarina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switching to ErrSegmentUnparsable would remove details on what part of the version failed to parse. It would be nice to keep that.

Switching to %w is something I would be immediately open to.

@crozzy crozzy force-pushed the add-new-error-type branch from a24cef3 to bb7a120 Compare November 19, 2024 20:52
@crozzy crozzy changed the title Add new error when int parsing fails Wrap parsing error to allow caller to discern why things failed Nov 19, 2024
It's hard to reason with errors when `strconv.ParseUint` fails as
the returned error is untyped. This change wraps the parsing error.

Signed-off-by: crozzy <[email protected]>
@crozzy crozzy force-pushed the add-new-error-type branch from bb7a120 to b40b53a Compare November 19, 2024 20:55
@crozzy crozzy requested a review from mattfarina November 19, 2024 20:59
@crozzy
Copy link
Author

crozzy commented Nov 19, 2024

Updated, one thing, I lower-cased those error strings to adhere to https://go.dev/wiki/CodeReviewComments#error-strings

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.

2 participants