-
-
Notifications
You must be signed in to change notification settings - Fork 282
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
error checking: accept Error() as alternative to String() #642
Comments
hey there - obviously I'm open to this but want to point out what currently exists first. You can do all this with: Expect(err).To(MatchError(SatisfyAll(
ContainSubstring(`Invalid value: "foo-"`),
ContainSubstring(`Invalid value: "bar.."`),
Not(ContainSubstring(`safe-and-unsafe`)),
Not(ContainSubstring("kernel.shmmax")),
)) (note you don't need the I could imagine expanding |
That looks promising. I think it can satisfy all cases that I had in mind for this issue, so we can (almost) close it. The output could be a bit better, though:
Dumping the error as struct makes sense because it may contain additional details. However, I would also expect to see the result of |
you can even avoid the "broken pavement" |
woof - yeah that failure message could use some work. will need to think about it - one areA i've been bumping into the last couple of days is the general problem of consistent and useful reporting when a (hierarchy of)submatcher(s) is involved. right now most composite matchers just print the i'm knee deep in another project right now but will add this to my todo list for when i free up. |
It's not just the matchers: the I'm thinking of this case:
I found that
This seems to be solved as a special case in |
Yes that makes sense - doing it at the |
hey sorry for the delay - i havent worked on the submatchers yet but the error output seemed like a higher priority anyway. it's now fixed on v1.27.3 - now anytime |
Note that
|
hey good catch. i've fixed this on master and rearranged things so |
That looks better, please cut a release. |
thanks for taking a look - 1.27.4 is out now with this change |
Looks like the godoc documentation for |
❤️ thank you!On Mar 24, 2023, at 1:28 PM, TheDiveO ***@***.***> wrote:
Looks like the godoc documentation for MatchError https://github.com/onsi/gomega/blob/5129b5cf7d54245b130b241a4ace8a0d12442ab1/matchers.go#LL90C4-L90C4 needs an update: it only mentions matching an error or a sting, but not using other matchers. Will work on this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
In Kubernetes, we (not often) check for specific errors:
I can currently write this as two assertions:
I would like to reduce this to one assertion:
This currently fails:
I think would be consistent with the gomega design to allow
error
as an alternative for afmt.Stringer
and to callError()
to obtain a string when given anerror
.The advantages are:
err
instead of many)The text was updated successfully, but these errors were encountered: