-
Notifications
You must be signed in to change notification settings - Fork 251
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
Bug: Errors aren't created with %w, breaking errors.Is #503
Labels
Comments
rkennedy
added a commit
to rkennedy/mage
that referenced
this issue
May 1, 2024
Wrapping errors instead of merely embedding error.messages allows calling code to use `errors.Is` and `errors.As` to more precisely check the reasons for various errors instead of having to rely only on substring searches. Fixes magefile#503
rkennedy
added a commit
to rkennedy/mage
that referenced
this issue
May 1, 2024
Wrapping errors instead of merely embedding error messages allows calling code to use `errors.Is` and `errors.As` to more precisely check the reasons for various errors instead of having to rely only on substring searches. Fixes magefile#503
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Description
In one of my build targets, I use
sh.Output
to check the output of a command. For example:But in my case, it's completely normal for "command" not to exist sometimes, so I want to handle that error differently from other failures that
sh.Output
might return. When the command doesn't exist, the underlyingos/exec
code will return anfs.PathError
, and the idiomatic way to check for that is to useerrors.Is
:But
errors.Is
returns false for errors returned bysh.Output
.What did you do?
As described above, I tried to use
errors.Is
to inspect errors returned bysh.Output
and other command-executing functions fromsh
.What did you expect to happen?
I expected
errors.Is
to recognize errors fromsh
functions as any of various common system errors, particularlyfs.ErrNotExist
.What actually happened?
errors.Is
fails to acknowledge that anysh
error is like any other known error.Environment
Additional context
This happens because errors in
sh
are constructed usingfmt.Errorf("...%v", err)
. That inserts the value oferr.String()
but does not actually wrap the error, so any additional information abouterr
is discarded. Changing it tofmt.Errorf("...%w", err)
would solve it without affecting any other behavior. Error wrapping was introduced in Go 1.13.My workaround for this issue is to inspect the text of the error message instead:
The text was updated successfully, but these errors were encountered: