在 package 中將錯誤消息與錯誤條件分開

Question

背景

包可以包含很多功能。 其中一些需要信息性錯誤消息，並且可能需要 function 中的一些注釋來解釋發生了什么/為什么發生。 例如，假設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

確實會引發錯誤，並且在它之上有一個很好的回溯並在控制台中使用調試選項重新運行。 此外，作為 package 的維護者，我更喜歡這樣做，因為它避免考慮編寫簡潔的 if 語句 + 1 行錯誤消息或在tryCatch語句中對齊注釋。

問題

是否有理由（不是對語法的看法）避免在conds.R中編寫 conds.R？

Answer 1

沒有理由避免寫conds.R 。 這是 package 開發中非常常見和良好的做法，特別是因為您想要做的許多檢查將適用於許多功能（如斷言輸入是字符，正如您在上面所做的那樣。這是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)
  }
}

盡管語法與您編寫的內容不同，但它旨在提供相同的行為，並表明可以包含在 package 中，並且沒有理由（根據我的理解）不這樣做。 但是，我會根據您上面的代碼添加一些語法點：

• 我會將 package 中的檢查（ if()語句）與錯誤提升捆綁在一起，以減少在您使用 function 的其他區域重復自己。
• 包含傳入的變量或參數的名稱通常更好，因此錯誤消息是明確的，例如在上面的dplyr示例中。 這使用戶更清楚錯誤是什么導致了問題，在這種情況下， x列在df中不是唯一的。
• 回溯顯示#> Error in e(2): oof, and error對用戶來說更加模糊，尤其是e()可能未在 NAMESPACE 中導出，他們需要解析源代碼以了解在哪里產生錯誤。 如果您使用stop(..., .call = FALSE ) 或通過嵌套函數傳遞調用環境，例如在join-cols.R中，那么您可以避免traceback()中的無用信息。 例如，在 Hadley 的Advanced R中建議這樣做：

默認情況下，錯誤消息包括調用，但這通常沒有用（並且概括了您可以從traceback()輕松獲得的信息），所以我認為使用call. = FALSE call. = FALSE