3

バックグラウンド

パッケージには多くの機能を含めることができます。それらのいくつかは、有益なエラーメッセージを必要とし、おそらく関数内に何が/なぜ起こっているのかを説明するコメントを必要とします. f1架空のf1.Rファイルの例。すべてのドキュメントとコメント (エラーの理由と状態の理由の両方) を 1 か所にまとめます。

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。

質問

パッケージに aを書くことを避ける理由 (構文に関する意見ではない) はありますか?conds.R

4

1 に答える 1