Closed nhorton closed 3 months ago
then devs often (udnerstandably) don't write a test for that case
IMO that's not a good assumption. Like anything else you'd rely on in a production environment, you should definitely cover error reporting logic with tests. For that reason, this SDK actually provides test helper, which you can access to with require "sentry/test_helper"
.
But at the same time, we didn't do a good job surfacing it to our users. I will open a PR to link API docs in the readme (#2300).
Take ** args and pass everything you don't recognize as extras
Ultimately, this depends on if Sentry want to give special treatments to extra attributes and how it could affect users' behaviour. While it's convenient for some users, it could, for example, lead to contexts
being under-utilized? I'll let @sl0thentr0py make the call.
Take ** args and pass everything you don't recognize as extras
hmm, we don't do this in other SDKs so I don't really want to change the semantics here, sorry!
I can make it clearer in the docs and also make sure it doesn't throw.
actually see this note https://docs.sentry.io/platforms/ruby/enriching-events/context/#additional-data
so yes we do prefer that you send contexts instead of extra.
We often get issues in code where somebody had an error condition where they had code like:
That is how structured logging is styled, and looks like it makes sense.
Sentry wants that instead to be:
The big problem with this though too is that if the only thing in the error handling was a Sentry capture, then devs often (udnerstandably) don't write a test for that case, and we only see the issue in prod when we get a syntax error on the above.
Couple things that would be nice: