Teach evaluate about condition handlers

[jennybc]

@lionel- and I have talked about this (https://github.com/tidyverse/reprex/issues/320#issuecomment-670358939) but I want to open a specific issue.

Until this happens, rlang::last_error() and rlang::last_trace() don't work, in general, in knitr and, therefore, in reprex. We can still do options("rlang:::force_unhandled_error" = TRUE) on a case-by-case basis, but @lionel- feels it does more harm than good if I were to make that global or default reprex behaviour.

[lionel-]

I experimented with this in:

• https://github.com/lionel-/evaluate/commit/e639b67e260b4aa7a853ca2c409f71bdf4429831
• https://github.com/lionel-/knitr/commit/61c17f56e623f546c1b20ea9c0e78e4841e21116

[hadley]

Would also be cool if evaluate could automatically cross-register global error handlers.

[lionel-]

This was implemented in https://github.com/r-lib/evaluate/pull/105

Would also be cool if evaluate could automatically cross-register global error handlers.

For expected errors you mean, because our try-catch prevents the global handlers from running? hmm... Interesting idea but automatically copying handlers on top of an existing R stack has the potential for unexpected behaviour. We'd need to check whether this has unintended effects with Ark for instance (I think it does). Alternatively we could require the handler to implement some interface that declares it's okay to copy it in nested "repl" contexts.

[hadley]

Ok great!

Yeah I also realised copying automatically is likely to be fraught. Might instead be better for evaluate to expose its own system for registering handlers. Anyway I’ll keep thinking about it as I work on evaluate.