将错误消息与包中的错误条件分开
Separating error message from error condition in package
背景
包可以包含很多功能。其中一些需要提供信息性错误消息,也许函数中的一些注释可以解释 what/why 正在发生。例如,假设的 f1.R
文件中的 f1
。所有文档和注释(错误原因和条件原因)都集中在一个地方。
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
语句中对齐注释。
问题
是否有理由(对语法没有意见)避免在包中写 conds.R
?
没有理由不写conds.R
。这在包开发中是非常普遍和良好的做法,特别是因为您想要做的许多检查将适用于许多功能(比如断言输入是字符,正如您在上面所做的那样。这是来自 [=13 的一个很好的例子=].
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
.[=41 中不是唯一的=]
- 在您的示例中显示
#> Error in e(2) : oof, and error
的回溯对用户而言更加模糊,特别是因为 e()
可能未在 NAMESPACE 中导出,他们需要解析源代码以了解产生错误。如果你使用 stop(..., .call = FALSE
) 或通过嵌套函数传递调用环境,如 join-cols.R,那么你可以避免 traceback()
中无用的信息。例如,这在 Hadley 的 Advanced R: 中建议
By default, the error message includes the call, but this is typically not useful (and recapitulates information that you can easily get from traceback()
), so I think it’s good practice to use call. = FALSE
背景
包可以包含很多功能。其中一些需要提供信息性错误消息,也许函数中的一些注释可以解释 what/why 正在发生。例如,假设的 f1.R
文件中的 f1
。所有文档和注释(错误原因和条件原因)都集中在一个地方。
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
语句中对齐注释。
问题
是否有理由(对语法没有意见)避免在包中写 conds.R
?
没有理由不写conds.R
。这在包开发中是非常普遍和良好的做法,特别是因为您想要做的许多检查将适用于许多功能(比如断言输入是字符,正如您在上面所做的那样。这是来自 [=13 的一个很好的例子=].
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
.[=41 中不是唯一的=] - 在您的示例中显示
#> Error in e(2) : oof, and error
的回溯对用户而言更加模糊,特别是因为e()
可能未在 NAMESPACE 中导出,他们需要解析源代码以了解产生错误。如果你使用stop(..., .call = FALSE
) 或通过嵌套函数传递调用环境,如 join-cols.R,那么你可以避免traceback()
中无用的信息。例如,这在 Hadley 的 Advanced R: 中建议
By default, the error message includes the call, but this is typically not useful (and recapitulates information that you can easily get from
traceback()
), so I think it’s good practice to usecall. = FALSE