3 ms·
Unless you running a million-user app, I believe you shouldn't fall for this. I have, multiple times. I've tried to catch what users were doing and get a log of
by fiatjaf 9y ago
Unless you running a million-user app, I believe you shouldn't fall for this. I have, multiple times. I've tried to catch what users were doing and get a log of the exceptions they faced. Only despair followed from these attempts.
The best error handling technique is to catch exceptions and show up a big popup on the screen with the error details.
Your users will send those details to you instead of just saying "the app crashed".
- mankz 9y agoYou sum it up well. If you just get static text (call stack etc) from your error logger tool, it's of almost no use as it doesn't reveal the state of the app. With modern tools that have replay capability, this changes and the debugging process is so much nicer. :)
- Can_Not 9y agoEvery error tracker I've ever used allows you to send arbitrary data (which could be your entire flux store, for example) and has great documentation on how to start using it.
- mankz 9y agoWe also allow you to attach any custom data to the error report. But this doesn't necessarily help you put the web application into the state where it crashes. Demo of custom data: https://app.therootcause.io/sandbox/addingcustomdata/ https://app.therootcause.io/sandbox/addingcustomdata/
- Can_Not 9y agoIn my experience, users can't be bothered to copy and paste those errors. One feature of <literally any error tracker> is to give the user a code instead of the raw stack. This pairs well with the feature to attach arbitrary data (like current state, or atleast just user id), then you can see the whole error data in the tool on your own computer. I've been able to fix bugs before the support staff approaches me about it.