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

Define base error type and use stdlib error wrapping #1662

Open
2 tasks
Tracked by #833
meatballhat opened this issue Jan 23, 2023 · 2 comments
Open
2 tasks
Tracked by #833

Define base error type and use stdlib error wrapping #1662

meatballhat opened this issue Jan 23, 2023 · 2 comments
Assignees
Labels
area/v3 relates to / is being considered for v3
Milestone

Comments

@meatballhat
Copy link
Member

meatballhat commented Jan 23, 2023

The stdlib error wrapping capability via fmt + %w allows for error wrapping as defined in the Go 2 error wrapping spec (citation needed) and as understood by the third-party errors package (and probably many others). The work to be done is:

  • define a const-ish "base" error type for errors that originate in this package
  • replace all runtime generated errors (errors.New) with error wrapping via fmt + %w
@meatballhat meatballhat added this to the Release 3.x milestone Jan 23, 2023
@dearchap dearchap added the area/v3 relates to / is being considered for v3 label Jun 12, 2023
@asahasrabuddhe asahasrabuddhe self-assigned this Aug 21, 2024
@dearchap
Copy link
Contributor

@asahasrabuddhe Are you working on this ?

@somebadcode
Copy link

Errors have become better in go and defining all errors as either a variable or a concrete type that satisfies the error interface is the way to properly deal with errors.

var (
	ErrInvalidSyntax = errors.New("invalid syntax")
)
type UnknownFlagError struct {
	Name string
}

func (e UnknownFlagError) Error() string {
	return fmt.Sprintf("unknown flag %q", e.Name)
}

Even if all errors aren't going to be used in error comparisons by the users of this package, having a consistent way of defining errors to allow the use of the facilities provided by the errors package is going to help in the long run and maintainability. So avoiding the use of errors.New inside functions and fmt.Errorf without the use of wrapping (verb %w) will make the overall experience with dealing with this package better.

I don't agree with having one base error but having a few errors that cover larger areas where more information can be provided via fields in the error type or wrapped using fmt.Errorf is a good approach. The names of the errors or error types should be easily understood so having one to rule them all is not a good approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v3 relates to / is being considered for v3
Projects
None yet
Development

No branches or pull requests

4 participants