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

make IsNil guard against nil underlying errors #64

Merged
merged 1 commit into from
Mar 12, 2020

Conversation

rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Mar 10, 2020

Almost everyone that uses quicktest for the first time uses
IsNil to check for errors, but there's a subtle mistake in doing so
because an error with a nil underlying value is not considered
to be nil for the usual err != nil error checking.

This change alters the semantics of IsNil to guard against
this case. If you really do want to check that a error-implementing
value is nil, you can still use qt.Equals.

Also add package-level docs for ContentEquals.

Copy link
Contributor

@mhilton mhilton left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Owner

@frankban frankban left a comment

Choose a reason for hiding this comment

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

Looks good with soem changes. Thanks!

checker.go Outdated
@@ -73,6 +73,34 @@ func (c *equalsChecker) Check(got interface{}, args []interface{}, note func(key
return nil
}

// NilError is a Checker that checks whether an error value is nil.
Copy link
Owner

Choose a reason for hiding this comment

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

I'd call it IsNilError:

  • it is similar to IsNil that we already have;
  • it will show up in autocompletion as an alternative to IsNil;
  • all other checkers are 3rd person verbs.

checker.go Outdated
}
return errors.New("got non-nil error")
}

Copy link
Owner

Choose a reason for hiding this comment

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

What do you think about hinting using this in the Equals checker when got is an error and want is nil?
We could add a hint with a note() for example.

checker_test.go Outdated
expectedNegateFailure: `
error:
bad check: value is not an error
`,
Copy link
Owner

Choose a reason for hiding this comment

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

Add a check with a nil concrete error type?

@rogpeppe rogpeppe changed the title add NilError checker make IsNil guard against nil underlying errors Mar 12, 2020
Copy link
Owner

@frankban frankban left a comment

Choose a reason for hiding this comment

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

Looks good with a doc change.
I think this is a great way to go. Thanks!

doc.go Outdated
@@ -214,6 +222,18 @@ For instance:
c.Assert("these are the voyages", qt.Matches, `these are .*`)
c.Assert(net.ParseIP("1.2.3.4"), qt.Matches, `1.*`)

NilError
Copy link
Owner

Choose a reason for hiding this comment

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

Please remove this and modify IsNil doc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Almost everyone that uses quicktest for the first time uses
IsNil to check for errors, but there's a subtle mistake in doing so
because an error with a nil underlying value is not considered
to be nil for the usual `err != nil` error checking.

This change alters the semantics of `IsNil` to guard against
this case. If you really do want to check that a error-implementing
value is nil, you can still use qt.Equals.

Also add package-level docs for ContentEquals.
@frankban frankban merged commit 94016c6 into frankban:master Mar 12, 2020
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.

None yet

3 participants