[GitHub] [arrow] paleolimbot opened a new issue, #34826: [R] Modernize error handling

["paleolimbot (via GitHub)" <gi...@apache.org>]

paleolimbot opened a new issue, #34826:
URL: https://github.com/apache/arrow/issues/34826

   ### Describe the bug, including details regarding any error messages, version, and platform.
   
   In a number of places we have a pattern where we do:
   
   ```r
   tryCatch(
     something_hard_with_confusing_errors(),
     error = function(e) {
       if (grepl("confusing error", conditionMessage(e)) {
         stop("A better error message")
       } else {
         stop(e)
       }
     }
   )
   ```
   
   When we do this we loose the backtrace of the confusing error (which, although confusing to the user, is a better indicator of where the error occurred when we try to debug it). In more than one case, inspecting the original error has resulted in one of us realizing that the original error was not the one we expected. In more than one case it has resulted in one of us (me at least) manually editing some code to generate a custom build that prints out the original error (as opposed to just running the code).
   
   Since we started doing this, rlang has made it relatively easy to throw a "classed error" and to include an original error in the backtrace so that you can do:
   
   ```r
   tryCatch(
     something_hard_with_confusing_errors(),
     some_custom_error_class = function(e) {
       abort("A better error message", parent = e)
     }
   }
   ```
   
   If for some reason the original error should really really really not get printed, we could inspect the value of REPREX_QUIET or ARROW_R_DEV (such that we could suggest that an issue opener set one of them and run their code again in the event their data is too big to reprex).
   
   ### Component(s)
   
   R


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [arrow] paleolimbot commented on issue #34826: [R] Modernize error handling

["paleolimbot (via GitHub)" <gi...@apache.org>]

paleolimbot commented on issue #34826:
URL: https://github.com/apache/arrow/issues/34826#issuecomment-1503836950

   Agreed! We could probably get the class specific to something like `arrow_status_invalid` or `arrow_status_not_implemented`. We emit just about everything from here: https://github.com/apache/arrow/blob/main/r/src/arrow_types.h#L99-L117
   
   Probably we'd need an R function like `stop_for_status()` that calls `rlang::abort()` (and then call it from C++).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [arrow] nealrichardson commented on issue #34826: [R] Modernize error handling

["nealrichardson (via GitHub)" <gi...@apache.org>]

nealrichardson commented on issue #34826:
URL: https://github.com/apache/arrow/issues/34826#issuecomment-1503782734

   I agree we can do better by using the new tooling. One thing that makes this a little trickier is that usually the error message we're inspecting comes from the Arrow C++ library, where we can't control what class the R error is. 
   
   I wonder if `cpp11`, or our custom wrapping, could at least add a class to the errors from cpp-land? That way, even if we still need to inspect the original error message to know what to do with it, you could limit that logic to the `cpp_error` class and not `error` in general, so that other kinds of errors would bubble up.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org