Open acobster opened 5 years ago
+1, I'd be happy to get the ball rolling with this as well.
More specific implementation details: https://docs.rollbar.com/reference
Required: "trace", "trace_chain", "message", or "crash_report" (exactly one) [...] If a message with no stack trace, use "message"
@ash14 thanks for the +1. I'm thinking maybe we expand core/notify
to accept a custom protocol, say, Loggable
, which we then extend to Throwable
and String
. Does that sound like the right approach to you?
Would love to hear from someone at CircleCI about this as well.
After looking at the docs a bit closer, these arbritrary messages can have arbritrary data as well.
So it looks like the user-facing API should support either of these forms:
(rollcage/error r err)
; "trace_chain": [{...}]
(rollcage/warn r "Request over threshold of 10 seconds")
; "message": {
; "body": "Request over threshold of 10 seconds"
; }
(rollcage/warn r "Request over threshold of 10 seconds" {:route "home#index"
:time_elapsed 15.23})
; "message": {
; "body": "Request over threshold of 10 seconds",
; "route": "home#index",
; "time_elapsed": 15.23
; }
This adds some complication though... I'd start with getting a core/build-trace
alternative to play nicely with those 3 forms and return the respective JSON key/value pair.
Protocols sound like a suitable implementation, yeah.
+1 context params are extremely important and useful not just for "arbitrary messages" but for regular exceptions as well.
The Rollbar PHP SDK (just as an example) allows for logging arbitrary messages to Rollbar:
This is really useful for certain kinds of remote debugging situations, e.g. when you haven't been able to reproduce a production error yet and need more contextual information.
What I'd like to be able to do in Clojure is something like:
As far as I can tell, though, this would require a change to the API of the
core/notify
fn, which always expects aThrowable
. I think it makes sense to have the Rollcage internals know what to do withThrowable
instances when it sees them, but the current API seems to preclude certain valid use-cases of the wider Rollbar API. Or maybe I'm missing something?Edit: to be clear, I'm happy to submit a PR for widening the API, but I thought it would be best to discuss what that wider API would look first. Thoughts?
Thanks!