Irene Steves
2018-Sep-14 09:16 UTC
[Rd] Suggestion: use mustWork = TRUE as the default for system.file
Hello all, Currently, the default behavior for system.file() is to return "" for faulty paths. I've found this behavior to be difficult when debugging, since it passes the empty path onto other functions. I initially wrote in errors myself (with code like `if(path == "") stop(?Path not found?)`), but I now use mustWork=TRUE or fs::path_package(), which errors by default. What are the general thoughts on this issue? I would love to see mustWork=TRUE become the default in future versions of R, but I would be happy to hear any counterarguments (or support!) for this suggestion. Cheers, Irene Steves [[alternative HTML version deleted]]
Tomas Kalibera
2018-Sep-17 05:02 UTC
[Rd] Suggestion: use mustWork = TRUE as the default for system.file
Hello Irene, we can only change the documented behavior when there is a very strong reason to do so, because it indeed can break existing code. A lot of existing code would depend on the current behavior, using e.g. nzchar() to check the output of system.file(). Changing the behavior that is used on error paths would be particularly tricky, because the error paths are typically not covered by tests (normally when considering a change I would run tests for all CRAN+BIOC packages to test if that change would be too disruptive, but it would not help in this case). I am afraid such a change is impossible. Best Tomas On 09/14/2018 02:16 AM, Irene Steves wrote:> Hello all, > > Currently, the default behavior for system.file() is to return "" for > faulty paths. > > I've found this behavior to be difficult when debugging, since it passes > the empty path onto other functions. I initially wrote in errors myself > (with code like `if(path == "") stop(?Path not found?)`), but I now use > mustWork=TRUE or fs::path_package(), which errors by default. > > What are the general thoughts on this issue? I would love to > see mustWork=TRUE become the default in future versions of R, but > I would be happy to hear any counterarguments (or support!) for this > suggestion. > > Cheers, > Irene Steves > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel