On Tuesday, June 25, 2013 5:02:43 PM UTC-4, a1 wrote: > >> You are attacking a strawman. I've commented on a very specific quote > from original post: > >> The alternative is to start removing catch clauses so that the app will, >> in fact, crash and the developer can at least see something. This seems >> like a silly approach, though. > > From this and rest of the post I get an impression (maybe wrong) that OP > catches aggressively everything - and this is of course invalid approach > (that makes debugging harder), and I did explain why. >
Well, I never said I was catching everything indiscriminately. I catch things that I can do something about. Sometimes there's a silent fall-back and the app doesn't even need to bother the user about it. Sometimes I need to involve the user in what to do next. Sometimes I simply tell the user that something didn't work. In all those cases, the app doesn't crash, but in many of those cases, as a developer I'd like to see what happened; there may be an underlying flaw in our code or an unforeseen incompatibility with the user's device. What I was asking about was whether there was a way of obtaining the benefits of a crash report without forcing the app to crash (that was what "removing catch clauses" was referring to). Call it a "glitch report". What I've been doing in cases where I tell the user that something went wrong is to provide a button that composes an email for the user to review and then send to us. This seems bad for several reasons: - it's a pain to code - users are often reluctant to send emails (or to take any action other than dismiss an error notification dialog) - an error message is already disruptive to the user; asking the user to take some action makes the disruption worse - it's out-of-band communication - it would be useful to report problematic events without involving the user (especially events for which the user would otherwise not need to be involved) I'll look into the ACRA-style bug reporting that TreKing suggests and at the crashlytics and android-log-collector tools suggested by Nathan. At first glance these look interesting, although something integrated with the developer console would be ideal. -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
