You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, wrapped exceptions, very common in Java, are not displayed at the moment and all the traces are just glued together with not indentation. It makes identifying the causes and other things a bit more difficult/impossible since the message from the cause is not displayed.
A very straightforward example of this issue would be this event: issues/4156/events/62029, which the cause would very likely be a exception from the IOException family.
In fact, I bet a lot of the issues that are in Sentry right now are of this kind, a network issue that abruptly left the extractor in a bad state (which should be detected and handled correctly to avoid a full on app crash).
I think it's mainly caused by the way the custom stack trace parsing works, maybe this should be done on the client side, which then would send the information in a sane format and avoid regex in the first place?
Don't know much about Sentry, but would be willing to fix some time in the future if nobody takes care of it.
The text was updated successfully, but these errors were encountered:
If sentry provides support for this kind of stacking etc., please feel free to implement it in NewPipe as well as here. I basically took what I got years ago, and haven't touched the code since. The whole crash reporting isn't really used as much by the developers, probably because it's not as useful as it could be, so any improvements are welcome.
To fix the issue with the custom stack trace parsing in Sentry not displaying wrapped exceptions and causing issues with identification of causes, the following process could be taken:
1. Review the current implementation of the custom stack trace parsing in Sentry to understand how it works and why it's not displaying wrapped exceptions correctly.
2. Determine if the issue is caused by the custom parsing method or if there are other underlying issues that need to be addressed.
3. Research best practices for displaying wrapped exceptions in Sentry or other similar error tracking platforms.
4. Implement changes to the custom stack trace parsing method to properly display wrapped exceptions and improve indentation of the error traces for easier identification of causes.
5. Test the changes thoroughly to ensure they do not cause any unintended consequences or introduce new bugs.
6. Deploy the changes to the production environment and monitor for any issues or errors.
For example, wrapped exceptions, very common in Java, are not displayed at the moment and all the traces are just glued together with not indentation. It makes identifying the causes and other things a bit more difficult/impossible since the message from the cause is not displayed.
A very straightforward example of this issue would be this event: issues/4156/events/62029, which the cause would very likely be a exception from the
IOException
family.In fact, I bet a lot of the issues that are in Sentry right now are of this kind, a network issue that abruptly left the extractor in a bad state (which should be detected and handled correctly to avoid a full on app crash).
I think it's mainly caused by the way the custom stack trace parsing works, maybe this should be done on the client side, which then would send the information in a sane format and avoid regex in the first place?
Don't know much about Sentry, but would be willing to fix some time in the future if nobody takes care of it.
The text was updated successfully, but these errors were encountered: