Error grouping and navigation issues
Allen Petersen
Posted on
Mar 04 2013
First let me say I really like Raygun, it has already provided us with a number of crash reports that we were not able to get from users directly.
There is a big problem with the error grouping though. It seems like errors are grouped by exception message only. This creates a problem when you have a generic crash like NullReferenceException and ArgumentOutOfRangeException.
If you have two very different NullReferenceExceptions they will be grouped together. This means I need to search through the whole set of errors for each crash with the Next/Previous buttons. Also once you resolve one it resolves them all. So I fix a NullRef bug now and next week a new one comes in I will not see it because it is already resolved.
That brings me to my second point, navigating a group of crash reports. It would be a lot easier if the Next/Previous buttons were not on the bottom of the page. It would be nice to be able to next and see enough detail to figure out if it is duplicate bug without having to scroll.
Along the same lines it would be nice to compact header mode for the error view. Shrink or minimize the graph and layout the rest of the data in a smaller area. Currently it takes 950 pixels (not including browser chrome) before the stack trace is visible.
Thanks, -allen
John-Daniel Trask
Raygun
Posted on
Mar 06 2013
Hi Allen,
We're working on improvements to grouping and to the navigation of error groups to make it much more easy to move around.
The next/back at the bottom for exception instances we generally feel makes senses (instance data at bottom, group data at top sort of thinking). Having something to page through the groups from the top though would be a great addition and something we've been asked for from a few people.
We're investigating a better responsive design for the page also. You rightly notice that the graph can get a bit large and we could use the space better (since launch we've been watching the screen sizes of our users -- they're pretty damn big which is great but it also means the default experience could be improved!).
We're going to get a blog running shortly and we'll be detailing more about the error grouping. We're aware it needs to be smarter and we also have a bunch of requests to let users connecting similar exceptions also, to train the system. This is particularly useful for some providers like the JavaScript provider - an error can look very different when it's actually the same but different browsers report it differently.
Thanks so much for your feedback, we're working as fast as we can to get a lot of these types of ideas incorporated into the product. We can't wait to have them in your hands!
andrew.myhre
Posted on
Sep 11 2013
Hi, This is still quite a frustrating issue. As well as grouping errors by message, it's also a good idea to combine it with the stack trace to make a unique key. In the past I've done this by generating at hash from the stack trace and the message combined. Using a hash as a key makes indexing a bit quicker too. Hope this helps. RayGun isn't really helping us squash our bugs at all because of this quirk. All we know is that errors are happening.
Thanks
tobs1701
Posted on
Sep 26 2013
Do you have any updates on the error grouping problem?
We have a difficult time with exceptions that originate in third partly libraries such as SQLite. Often exceptions aren't raised until 4-5 stack frames deep into the library. The calls, however, are in dozens of locations throughout our application resulting in individual occurrences that may require different solutions.
How hard would it be to differentiate errors via the full stack trace? Or, even better, to set grouping preferences by application?
jeremy
Raygun
Posted on
Sep 26 2013
If you would like we can flip a nominated application over to a different classification function which does inspect the stack trace rather than using the message for grouping so you can see how this changes the way your errors are being grouped. Keep in mind this does not apply to any existing data so you will start seeing new groups created for all errors if we flip this over for you.
Let us know if you want to look at this.
We are looking into how we can offer more flexibility around classification but we dont have anything concrete planned for release at this stage.
Jeremy
andrew.myhre
Posted on
Oct 04 2013
Hi Jeremy, Yes, please do this for all of our applications.
Thanks