The rlang 1.0.0 error style doesn't stop code execution as expected

[Tavo_Cera]

Hi all, as explained in this blog post here, rlang new 1.0.0 version displays errors in a "message" style.

As you will see on the reprex below, there are two errors in two separate mutate function statements. Those two are displayed as messages and only the third one, using filter, returns an error and stops the execution of the entire code.

This example is a toy version to explain my issue: I expect R to stop the execution of my code once the first error occurs. This would help me debug. Following code shouldn't be run if there are previous errors happening.

Note: I intentionally spelled "gear" wrong to cause the error. You will notice that mtcars_2 can't be created because the first new variable doesn't exist. Then, the filter can't be done.

Is there a way to bring back the error "nature" to stop code run rather than just return a message and continue with the following code?

library(tidyverse)
sessionInfo()
#> R version 3.6.3 (2020-02-29)
#> Platform: x86_64-w64-mingw32/x64 (64-bit)
#> Running under: Windows 10 x64 (build 19044)
#> 
#> Matrix products: default
#> 
#> locale:
#> [1] LC_COLLATE=English_United States.1252 
#> [2] LC_CTYPE=English_United States.1252   
#> [3] LC_MONETARY=English_United States.1252
#> [4] LC_NUMERIC=C                          
#> [5] LC_TIME=English_United States.1252    
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> other attached packages:
#> [1] forcats_0.5.0   stringr_1.4.0   dplyr_1.0.8     purrr_0.3.4    
#> [5] readr_1.3.1     tidyr_1.0.2     tibble_3.1.6    ggplot2_3.3.0  
#> [9] tidyverse_1.3.0
#> 
#> loaded via a namespace (and not attached):
#>  [1] tidyselect_1.1.2 xfun_0.30        haven_2.2.0      lattice_0.20-38 
#>  [5] colorspace_1.4-1 vctrs_0.4.1      generics_0.0.2   htmltools_0.5.2 
#>  [9] yaml_2.2.1       utf8_1.1.4       rlang_1.0.2      pillar_1.7.0    
#> [13] glue_1.6.2       withr_2.5.0      DBI_1.1.0        dbplyr_1.4.2    
#> [17] readxl_1.3.1     modelr_0.1.6     lifecycle_1.0.1  cellranger_1.1.0
#> [21] munsell_0.5.0    gtable_0.3.0     rvest_0.3.5      evaluate_0.15   
#> [25] knitr_1.38       fastmap_1.1.0    fansi_0.4.1      highr_0.8       
#> [29] broom_0.5.5      Rcpp_1.0.3       backports_1.1.5  scales_1.1.0    
#> [33] jsonlite_1.6.1   fs_1.3.2         hms_0.5.3        digest_0.6.25   
#> [37] stringi_1.4.6    grid_3.6.3       cli_3.2.0        tools_3.6.3     
#> [41] magrittr_1.5     crayon_1.3.4     pkgconfig_2.0.3  ellipsis_0.3.2  
#> [45] xml2_1.2.4       reprex_2.0.1     lubridate_1.7.4  assertthat_0.2.1
#> [49] rmarkdown_2.13   httr_1.4.2       rstudioapi_0.11  R6_2.4.1        
#> [53] nlme_3.1-144     compiler_3.6.3

mtcars <- mtcars %>% 
  mutate(new_gear = geer^2)
#> Error in `mutate()`:
#> ! Problem while computing `new_gear = geer^2`.
#> Caused by error:
#> ! object 'geer' not found

mtcars <- mtcars %>% 
  mutate(new_carb = carb^2)

mtcars_2 <- mtcars %>% 
  mutate(new_x = new_gear + new_carb)
#> Error in `mutate()`:
#> ! Problem while computing `new_x = new_gear + new_carb`.
#> Caused by error:
#> ! object 'new_gear' not found

mtcars_2 %>% 
  filter(new_x > 15)
#> Error in eval(lhs, parent, parent): object 'mtcars_2' not found

[nirgrahamuk]

I'm afraid you may have a misconception.
the rlang/dplyr changes have impacted how the error is reported / printed to console etc. but there is no change to how R handles code execution etc.

How are you executing your code in R studio? if you hit the source() button or CTRL+ALT+R to run all, you will get the early code stoppage you describe as desirable, contrarily: if you select all the text with cursor controls and submit them to run via ALT+ENTER, then an earlier error will not necessarily cause later code to be skipped, as this mode of running code is the equivalent of you manually typing each code statement into the console one after the other 'independently' so an error will not cause your next code statement to not be evaluated.

[Tavo_Cera]

That makes a lot of sense, thanks for the explanation. I have to say I am not running this on R Studio, is actually on Cloudera's CDSW instead. It allows you to set up automated jobs from scripts. I'm not entirely sure how it runs code, but I suppose it does it in a similar way as the latter you exposed.

Anyway, thanks for the detailed response! I understand now the issue is not rlang related, but how the code is executed.