More useful stack traces

[jcpsantiago]

https://renkun.me/2020/03/31/a-simple-way-to-show-stack-trace-on-error-in-r/

has some ideas about making stack traces more informative. could be useful for sentryR.

[egnor]

What in particular could be useful from that post?

[jcpsantiago]

It shows how to get to the actual functions calls, which what one wants most of the time IMO, otherwise you can't retrace what happened. At the moment, the stack trace in SentryR is created with https://github.com/EduSemensati/sentryR/blob/b4d0767736f7ebc3b4916a078c6c4d0a44d59890/R/calls.R#L12 are not as "clean". So an idea could be to replicate that blog post e.g. in the function that wraps endpoints and /or capture.

I have to be honest, I haven't given this a lot of thought. Mostly because the current stack traces have been "good enough" and nobody else complained, but I'm always open to ideas :D

[egnor]

I'm not sure what you mean about "getting to the actual function calls"? Isn't that what sentryR already does?

There's a few different suggestions in that blog post

• use traceback, which dumps the current stack to stdout (not really useful here)
• (sentryR could use .traceback, but really that just walks sys.calls and formats the result)
• limit the number of stack entries to a small amount (e.g. 3)
• limit the number of lines printed from each stack entry to a small amount (e.g. 1)
• write one's own formatter for sys.calls, which is exactly what sentryR does
• use the rlang package which provides its own stack trace capture handler

At the end of the data everything is just some transformation of the output of sys.calls, which is what sentryR is already doing, so I'm not sure which suggestion you feel like might be helpful.

I actually experimented a bit with rlang and its error handling. It has pretty formatting tools and adds handlers to attach stack chains to errors whenever it sees them. However it wasn't actually super helpful in my case, because the handlers I would use to route errors to Sentry would always come before the rlang handler, which meant I didn't really get extra information.

The biggest problem I've had with sentryR's stack reporting (besides the various bugs I've been reporting!) is that when code uses a tryCatch and then wants to report the error to Sentry, the useful context of the actual error is lost-- you only get the stack up to the tryCatch itself and not to the point that actually signaled the error. To do better one should use withCallingHandlers, and we have our own with_sentry wrapper that does that, but in existing code that's not always feasible to insert.

[apit]

why are they so different? i'm very new to R. is this related to #25? I tried gh-29 but i didn't notice any difference.

[egnor]

why are they so different? i'm very new to R. is this related to #25? I tried gh-29 but i didn't notice any difference.

I'm not sure the reason for all the differences-- perhaps something about shiny's control flow model?-- but a big one is that the console is printing the trace at the moment where it happens, but sentryR is getting the trace in the tryCatch handler (an issue noted above).