Review all error messages

[krlmlr]

Refactor

• test against known output
• use classed conditions
• use attributes for classed conditions

Add new

• expect_error_relax()
• existing examples in "invariants"
• use verify_output() for invariants
• usages that are not explicitly allowed in "invariants"
• warnings

[lionel-]

[[ can now use vctrs::vec_as_position():

vctrs::vec_as_position(100, length(mtcars), names = names(mtcars))
#> Error: Must index existing elements.
#> x Can't subset position 100.
#> i There are only 11 elements.

vctrs::vec_as_position("foo", length(mtcars), names = names(mtcars))
#> Error: Must index existing elements.
#> x Can't subset element with unknown name `foo`.

vctrs::vec_as_position(new.env(), length(mtcars), names = names(mtcars))
#> Error: Must extract with a single position or name.
#> x `i` has the wrong type `environment`.
#> i Positions and names must be integer or character.

vctrs::vec_as_position(factor("cyl"), length(mtcars), names = names(mtcars))
#> [1] 2

[krlmlr]

Thanks. Is there a way to replace "elements" by "columns" in the error messages? I remember a solution to a similar problem in tidyselect.

[lionel-]

We have decided to use a generic "element" for simplicity (for now at least).

[lionel-]

You can now override cnd_issue() to mention columns and data frames. See https://github.com/r-lib/tidyselect/pull/124/files#diff-a6d08219ee9b1f34a3ebbdedbe63b321 for an example.

The issue message should probably be as consistent as possible as the parent error's.

[krlmlr]

Relevant: tidyverse/design#100.

[krlmlr]

@lionel-: If we create a condition from a parent condition, is it good practice to copy over the detail information from the parent condition (such as location)?

[lionel-]

I think the better practice is to implement bullets methods that forwards to the parent. But we are only discovering these things :)

We don't have a cnd_details() method yet but we will in the next rlang version.

[krlmlr]

Thanks. I'd rather not have any methods for condition classes, they clutter NAMESPACE. The formula/function interface is more than enough for this use case I think. (And these are very easy to copy.)

[lionel-]

I don't think cluttering NAMESPACE should be a concern in any circumstance though. Unlike the pkgdown reference, which is easy to free of clutter.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.