Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have some questions regarding whether to crash or report errors to the user. We are developing a web site and mobile clients in which we allow our users to report any bugs and crashes through e-mail. We require the user to send the e-mail from their e-mail account, so they can be identified. Here are some questions regarding it:

  1. We used to send the last stacktrace of java when user presses "send error report" button. As it has only technical details that user may not understand or care about, is it necessary to show this stacktrace to the user?

  2. What if the user is concerned about privacy? Is it good practice to collect stacktraces of crashes and unusual behavior keeping user's privacy in mind? If it's not what are the other alternatives?

  3. For mobile devices what if the user wants to send an error report to the server but there is not any network connectivity, is it necessary to have a record of this type of common errors that is not related to application?

share|improve this question
1  
What other "crash report" applications have you seen? Please list some examples and what they do. Please find some specific examples of what other software does and talk specifically about those examples. –  S.Lott May 24 '11 at 10:27
add comment

2 Answers

up vote 3 down vote accepted

My two cents.

Keep in mind, this particular community is likely to be a cross section of programmers, so we aren't your average user. :) I can see reading my own thoughts that I'm answering as the "user who knows how to program", and not a regular human being.

  • We used to send the last stacktrace of java when user presses "send error report" button. As it has only technical details that user may not understand or care about, is it necessary to show this stacktrace to the user?

As a geeky user, I like to have the option (but not the obligation) to see the stacktrace. Oddly, about my best example is Microsoft - when something goes hideously wrong in some cases they give a "see details" button that gives me the stack trace. 9 times out of 10 I'll either not click the button, or click it, stare at it, and send it. But once and a while, I get just enough esoteric information out of it that I can change my behavior and get the app to do what I want.

  • What if the user is concerned about privacy? Is it good practice to collect stacktraces of crashes and unusual behavior keeping user's privacy in mind? If it's not what are the other alternatives?

I think you need to give the user both options and information. To me that's the ethical thing. My Android mobile apps give me a warning, first - "this app will send detailed error information about the state of your device to the company when an error occurs". That's very wordy, I suspect there's a better way to say it.

Then, I think the feature is either a persistent setting and/or a case by case option to turn off the error reporting. Personally, I prefer case by case, since I may make the decision based on current conditions - how big of a problem was it? How high is my bandwidth? etc.

  1. For mobile devices what if the user wants to send an error report to the server but there is not any network connectivity, is it necessary to have a record of this type of common errors that is not related to application?

IMO - for mobile apps, no. To me, there's an implied contract that my mobile apps will not fill my phone with error information just so it can be relayed when connectivity returns. I might expect that from an email app, where I'm trying to send some content, but I don't expect it from errors. I think when you are designing remote error reporting you have to assume you're going to loose a fair number of errors, so the error reports you get at the central server are not representative of every error that ever occurred remotely.

I'm sure mileage varies with the practicality of the system. Fortunately, I can't think of an application in your average mobile phone that is directly connected to the preservation of human life...

share|improve this answer
    
Thanks a lot, your answer gave me more clear vision for the app. –  Prasham May 24 '11 at 15:40
add comment
  1. Always show the stack trace. A magic mail is opening doors for law suits.
  2. Always respect privacy. See point 1 above - that is the option for user to deny sending it to you if they find any private info. Ideally NONE of the parameters should come to you.
  3. Always have an EULA that gets them to agree to this. Again, law suits.
  4. I have seen mobile apps that overwrite a single error file until they get connectivity - I have also seen mobile apps that reserve space in their file format for stats/error info. you could try one of that.
  5. When programs go out, I am assuming your stack trace might not contain all the information you need because of obfuscation etc. So ensure you have your release symbols cached and so on. Try checking out a core dump as a test case for every release - nothing worse than getting a malformed file.
  6. If you are indeed getting stacktraces, then your app might be reverse engineerable. Take care there if you are worried about IP.
share|improve this answer
    
Thanks, Upvote for 3,5 and 6 –  Prasham May 24 '11 at 15:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.