Build and test custom errors with base versus rlang
Open
Nobody has claimed this yet.
unit-testting
- Dominant language
- No language data
- Stars
- 17
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
# A custom error with base
f <- function() {
message <- paste(c("Oh no", "Messed up", "Need a hint?"), collapse = "\n")
# Construct a custom class via `errorCondition()`
stop(errorCondition(message, class = "my_error"))
}
# How it prints
f()
#> Error: Oh no
#> Messed up
#> Need a hint?
# How to test it
testthat::expect_error(tools::assertError(f(), classes = "my_error"), NA)
# A custom error with rlang
f <- function() {
# `x`, `i`, and unnamed bullets print nicely via `rlang::format_error_bullets()`
message <- c("Oh no", x = "Messed up", i = "Need a hint?")
# Construct a custom class direcly via `rlang::abort()`
rlang::abort(message, class = "my_error")
}
# How it prints
f()
#> Error: Oh no
#> x Messed up
#> ℹ Need a hint?
# How to test it
testthat::expect_error(f(), class = "my_error")
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the inline R examples using errorCondition(), tools::assertError(), rlang::abort(), and testthat::expect_error(). No target file, requested change, or acceptance criteria is given, so the intended documentation update and definition of done need clarification.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100