4 ms·
>And the stack trace was about three frames and discarded all the context - all I could see was that ActiveRecord was throwing a fit over somehow mysteriously r
by meowface 5y ago
>And the stack trace was about three frames and discarded all the context - all I could see was that ActiveRecord was throwing a fit over somehow mysteriously receiving a large number somehow.
This is Python rather than Ruby, but my average debugging time and frequency of "impossible to figure out" bugs drastically decreased once I started using a traceback library that provides a lot of context to each stack frame.
It makes logs containing any raised exceptions much larger and more tedious to scroll through, but the benefits are more than worth it; especially for production services.
I use better-exceptions (https://github.com/Qix-/better-exceptions https://github.com/Qix-/better-exceptions), but there are a bunch of other good libraries as well.
- Groxx 5y agoYeah, when we turned this feature on in Sentry a few years back, bugs got so much easier to fix. 90% of the time the stack trace and all arguments along the way were sufficient to figure out the full cause just from reading, no need to try to reproduce. It is enormously CPU-expensive though, so it can be risky in production. Small-ish error spikes can cause enough latency to cause more errors, which cause more latency...