R 스크립트 줄 번호 오류?

R 스크립트 줄 번호 오류?

---

명령 줄 (R --slave script.R)에서 긴 R 스크립트를 실행하는 경우 오류시 줄 번호를 제공하려면 어떻게해야합니까?

가능한 경우 스크립트에 디버그 명령을 추가하고 싶지 않습니다. R이 대부분의 다른 스크립팅 언어처럼 동작하기를 원합니다.

---

이것은 줄 번호를 제공하지 않지만 호출 스택에서 오류가 발생하는 위치를 알려줍니다. 이는 매우 유용합니다.

traceback()

[편집 :] 명령 줄에서 스크립트를 실행할 때 한두 번의 호출을 건너 뛰어야 합니다. 대화 형 및 비대화 형 R 세션에 대해서는 traceback ()을 참조하십시오.

일반적인 디버깅 용의자없이이 작업을 수행하는 다른 방법을 알지 못합니다.

1. 디버그 ()
2. 브라우저 ()
3. options (error = recover) [되돌리려면 options (error = NULL)가 이어짐]

이 관련 게시물을보고 싶을 수 있습니다.

[편집 :] 죄송합니다 ... 명령 줄에서 실행중인 것을 봤습니다. 이 경우 옵션 (오류) 기능을 사용하는 것이 좋습니다. 다음은 간단한 예입니다.

options(error = quote({dump.frames(to.file=TRUE); q()}))

오류 조건에 대해 원하는대로 정교한 스크립트를 만들 수 있으므로 디버깅에 필요한 정보를 결정해야합니다.

그렇지 않고, 당신이 염려하는 특정 영역이 있다면 (예 : 데이터베이스에 연결), tryCatch () 함수로 감싸십시오.

---

Doing options(error=traceback)은 오류로 이어지는 행의 내용에 대한 정보를 조금 더 제공합니다. 오류가 있으면 트레이스 백이 나타나고 일부 오류의 경우 줄 번호가 접두사로 붙습니다 #. 그러나 히트 또는 실패, 많은 오류가 줄 번호를 얻지 못합니다.

---

이에 대한 지원은 R 2.10 이상에서 제공 될 예정입니다. Duncan Murdoch는 2009 년 9 월 10 일에 findLineNum 및 setBreapoint 에 대해 r-devel에 게시했습니다 .

디버깅을 돕기 위해 R-devel에 몇 가지 기능을 추가했습니다. findLineNum()소스 코드의 특정 줄에 해당하는 함수의 줄을 찾습니다. setBreakpoint()의 출력을 취하고 거기에 중단 점을 설정하기 위해 findLineNum호출 trace()합니다.

이는 코드에 소스 참조 디버그 정보가 있어야합니다. 에서 읽은 코드의 기본값 source()이지만 패키지에는 적용되지 않습니다. 패키지 코드에서 소스 참조를 가져 오려면 환경 변수를 설정 R_KEEP_PKG_SOURCE=yes하거나 R 내에서 설정 options(keep.source.pkgs=TRUE)한 다음 소스 코드에서 패키지를 설치합니다. ?findLineNum검색을 전역 환경으로 제한하지 않고 패키지 내에서 검색하도록 지시하는 방법에 대한 자세한 내용을 읽으십시오 .

예를 들면

x <- " f <- function(a, b) {
             if (a > b)  {
                 a
             } else {
                 b
             }
         }"


eval(parse(text=x))  # Normally you'd use source() to read a file...

findLineNum("<text>#3")   # <text> is a dummy filename used by
parse(text=)

이것은 인쇄됩니다

 f step 2,3,2 in <environment: R_GlobalEnv>

그리고 당신은 사용할 수 있습니다

setBreakpoint("<text>#3")

거기에 중단 점을 설정합니다.

코드에는 여전히 몇 가지 제한 (그리고 아마도 버그)이 있습니다. 나는 thos를 고칠거야

---

설정하여 수행

options(show.error.locations = TRUE)

이 설정이 R에서 기본값이 아닌 이유가 궁금합니다. 다른 모든 언어와 마찬가지로 그래야합니다.

---

치명적이지 않은 오류를 처리하기위한 전역 R 옵션을 지정하면 오류에 대한 정보를 유지하고 실패 후이 정보를 검사하는 사용자 지정 워크 플로와 함께 저에게 효과적이었습니다. 현재 R 버전 3.4.1을 실행하고 있습니다. 아래에는 저에게 도움이 된 워크 플로에 대한 설명과 R에서 전역 오류 처리 옵션을 설정하는 데 사용한 일부 코드가 포함되어 있습니다.

내가 구성했듯이 오류 처리는 오류 발생시 작업 메모리의 모든 개체를 포함하는 RData 파일도 생성합니다. 이 덤프는를 사용하여 R로 다시 읽을 수 있으며 load()오류 발생 당시 존재했던 다양한 환경은를 사용하여 대화식으로 검사 할 수 있습니다 debugger(errorDump).

traceback()스택 내의 모든 사용자 지정 함수 의 출력에서 줄 번호를 얻을 수 있었지만 스크립트에 사용 된 사용자 지정 함수를 keep.source=TRUE호출 할 때 옵션을 사용한 경우에만 해당됩니다 source(). 이 옵션이 없으면 아래와 같이 전역 오류 처리 옵션을 설정하면의 전체 출력 traceback()이라는 오류 로그로 전송 error.log되지만 줄 번호를 사용할 수 없습니다.

다음은 워크 플로에서 수행 한 일반적인 단계와 비대화 형 R 실패 후 메모리 덤프 및 오류 로그에 액세스 할 수 있었던 방법입니다.

1. I put the following at the top of the main script I was calling from the command line. This sets the global error handling option for the R session. My main script was called myMainScript.R. The various lines in the code have comments after them describing what they do. Basically, with this option, when R encounters an error that triggers stop(), it will create an RData (*.rda) dump file of working memory across all active environments in the directory ~/myUsername/directoryForDump and will also write an error log named error.log with some useful information to the same directory. You can modify this snippet to add other handling on error (e.g., add a timestamp to the dump file and error log filenames, etc.).

   options(error = quote({
     setwd('~/myUsername/directoryForDump'); # Set working directory where you want the dump to go, since dump.frames() doesn't seem to accept absolute file paths.
     dump.frames("errorDump", to.file=TRUE, include.GlobalEnv=TRUE); # First dump to file; this dump is not accessible by the R session.
     sink(file="error.log"); # Specify sink file to redirect all output.
     dump.frames(); # Dump again to be able to retrieve error message and write to error log; this dump is accessible by the R session since not dumped to file.
     cat(attr(last.dump,"error.message")); # Print error message to file, along with simplified stack trace.
     cat('\nTraceback:');
     cat('\n');
     traceback(2); # Print full traceback of function calls with all parameters. The 2 passed to traceback omits the outermost two function calls.
     sink();
     q()}))
   

2. Make sure that from the main script and any subsequent function calls, anytime a function is sourced, the option keep.source=TRUE is used. That is, to source a function, you would use source('~/path/to/myFunction.R', keep.source=TRUE). This is required for the traceback() output to contain line numbers. It looks like you may also be able to set this option globally using options( keep.source=TRUE ), but I have not tested this to see if it works. If you don't need line numbers, you can omit this option.

3. From the terminal (outside R), call the main script in batch mode using Rscript myMainScript.R. This starts a new non-interactive R session and runs the script myMainScript.R. The code snippet given in step 1 that has been placed at the top of myMainScript.R sets the error handling option for the non-interactive R session.
4. Encounter an error somewhere within the execution of myMainScript.R. This may be in the main script itself, or nested several functions deep. When the error is encountered, handling will be performed as specified in step 1, and the R session will terminate.
5. An RData dump file named errorDump.rda and and error log named error.log are created in the directory specified by '~/myUsername/directoryForDump' in the global error handling option setting.

6. At your leisure, inspect error.log to review information about the error, including the error message itself and the full stack trace leading to the error. Here's an example of the log that's generated on error; note the numbers after the # character are the line numbers of the error at various points in the call stack:

   Error in callNonExistFunc() : could not find function "callNonExistFunc"
   Calls: test_multi_commodity_flow_cmd -> getExtendedConfigDF -> extendConfigDF
   
   Traceback:
   3: extendConfigDF(info_df, data_dir = user_dir, dlevel = dlevel) at test_multi_commodity_flow.R#304
   2: getExtendedConfigDF(config_file_path, out_dir, dlevel) at test_multi_commodity_flow.R#352
   1: test_multi_commodity_flow_cmd(config_file_path = config_file_path, 
   spot_file_path = spot_file_path, forward_file_path = forward_file_path, 
   data_dir = "../", user_dir = "Output", sim_type = "spot", 
   sim_scheme = "shape", sim_gran = "hourly", sim_adjust = "raw", 
   nsim = 5, start_date = "2017-07-01", end_date = "2017-12-31", 
   compute_averages = opt$compute_averages, compute_shapes = opt$compute_shapes, 
   overwrite = opt$overwrite, nmonths = opt$nmonths, forward_regime = opt$fregime, 
   ltfv_ratio = opt$ltfv_ratio, method = opt$method, dlevel = 0)
   

7. At your leisure, you may load errorDump.rda into an interactive R session using load('~/path/to/errorDump.rda'). Once loaded, call debugger(errorDump) to browse all R objects in memory in any of the active environments. See the R help on debugger() for more info.

This workflow is enormously helpful when running R in some type of production environment where you have non-interactive R sessions being initiated at the command line and you want information retained about unexpected errors. The ability to dump memory to a file you can use to inspect working memory at the time of the error, along with having the line numbers of the error in the call stack, facilitate speedy post-mortem debugging of what caused the error.

---

First, options(show.error.locations = TRUE) and then traceback(). The error line number will be displayed after #

참고URL : https://stackoverflow.com/questions/1445964/r-script-line-numbers-at-error