将错误消息与包中的错误条件分开答案

【问题标题】：Separating error message from error condition in package将错误消息与包中的错误条件分开
【发布时间】：2022-01-01 20:01:27
【问题描述】：

背景

包可以包含很多功能。其中一些需要信息性错误消息，并且可能需要函数中的一些 cmets 来解释发生了什么/为什么发生。例如，f1 在假设的f1.R 文件中。所有文档和 cmets（错误原因和条件）都集中在一个地方。

f1 <- function(x){
  if(!is.character(x)) stop("Only characters suported")
  # user input ...
  # .... NaN problem in g()
  # .... 
  # ratio of magnitude negative integer i base ^ i is positive
  if(x < .Machine$longdouble.min.exp / .Machine$longdouble.min.exp) stop("oof, an error")
  log(x)
}

f1(-1)
# >Error in f1(-1) : oof, an error

例如，我创建了一个单独的conds.R，指定了一个函数（以及w 警告、s 建议）等。

e <- function(x){
  switch(
    as.character(x),
    "1" = "Only character supported",
    # user input ...
    # .... NaN problem in g()
    # .... 
    "2" = "oof, and error") |>
    stop()
}

然后在f.R 脚本中，我可以将f2 定义为

f2 <- function(x){
  if(!is.character(x)) e(1)
  # ratio of magnitude negative integer i base ^ i is positive
  if(x < .Machine$longdouble.min.exp / .Machine$longdouble.min.exp) e(2)
  log(x)
}

f2(-1)
#> Error in e(2) : oof, and error

确实会引发错误，并且在它之上有一个很好的回溯并在控制台中使用调试选项重新运行。此外，作为包维护者，我更喜欢这个，因为它避免考虑编写简洁的 if 语句 + 1 行错误消息或在 tryCatch 语句中对齐 cmets。

问题

是否有理由（对语法没有意见）避免在包中写 conds.R？

【问题讨论】：

标签： r error-handling package-development

【解决方案1】：

没有理由避免写conds.R。这在包开发中是非常常见和良好的做法，特别是因为您想要执行的许多检查将适用于许多函数（如断言输入是字符，正如您在上面所做的那样。这是来自dplyr 的一个很好的例子.

library(dplyr)

df <- data.frame(x = 1:3, x = c("a", "b", "c"), y = 4:6)
names(df) <- c("x", "x", "y")
df
#>   x x y
#> 1 1 a 4
#> 2 2 b 5
#> 3 3 c 6

df2 <- data.frame(x = 2:4, z = 7:9)

full_join(df, df2, by = "x")
#> Error: Input columns in `x` must be unique.
#> x Problem with `x`.

nest_join(df, df2, by = "x")
#> Error: Input columns in `x` must be unique.
#> x Problem with `x`.

traceback()
#> 7: stop(fallback)
#> 6: signal_abort(cnd)
#> 5: abort(c(glue("Input columns in `{input}` must be unique."), x = glue("Problem with {err_vars(vars[dup])}.")))
#> 4: check_duplicate_vars(x_names, "x")
#> 3: join_cols(tbl_vars(x), tbl_vars(y), by = by, suffix = c("", ""), keep = keep)
#> 2: nest_join.data.frame(df, df2, by = "x")
#> 1: nest_join(df, df2, by = "x")

在这里，两个函数都依赖于join-cols.R 编写的代码。两者都调用join_cols()，后者又调用check_duplicate_vars()，我从以下位置复制了源代码：

check_duplicate_vars <- function(vars, input, error_call = caller_env()) {
  dup <- duplicated(vars)
  if (any(dup)) {
    bullets <- c(
      glue("Input columns in `{input}` must be unique."),
      x = glue("Problem with {err_vars(vars[dup])}.")
    )
    abort(bullets, call = error_call)
  }
}

虽然语法与您编写的内容不同，但它旨在提供相同的行为，并表明可以包含在一个包中，并且没有理由（据我的理解）不这样做。但是，我会根据您上面的代码添加一些语法点：

我会将检查（if() 语句）与错误提示捆绑在包内，以减少在您使用该功能的其他领域重复自己。
通常最好包含传入的变量或参数的名称，这样错误消息就很明确了，例如上面的dplyr 示例。这使用户更清楚错误是什么导致了问题，在这种情况下，x 列在df 中不是唯一的。
在您的示例中显示#> Error in e(2) : oof, and error 的回溯对用户来说更加模糊，尤其是e() 可能未在名称空间中导出，他们需要解析源代码以了解错误的生成位置。如果您使用stop(..., .call = FALSE) 或通过嵌套函数传递调用环境，例如join-cols.R，那么您可以避免traceback() 中的无用信息。例如，在 Hadley 的 Advanced R 中建议：

默认情况下，错误消息包括调用，但这通常没有用（并且概括了您可以从traceback() 轻松获得的信息），所以我认为使用call. = FALSE 是一个好习惯

【讨论】：