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: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? 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?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?
Crash and error report to developer [from user perspective]
error messages;bug report;privacy
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.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...