Error handling and reporting

General Discussions
#1

I’m wondering if anyone has any suggestions on how best to handle unrecoverable errors in the shipped version of an app.

Ideally there’d be an interactive dialog that gave the user the opportunity to submit a log file via email or other means, but it could take a fair amount of work to get the infrastructure for this in place (which I’d like to avoid if possible), and it might require including additional libraries (which I’m also trying to avoid).

Another option is writing log files to a folder (prepended with ‘.’ so as to be hidden on OSs that support it) in the user’s home directory, then showing a dialog informing the user what happened.

There seems to be plenty of precedent for this approach, but searching the forums here suggests that people might not like apps writing to their home directories. Also, casual users may not know how to (or have any inclination to) access the log files, rendering them of limited use. Lastly, it seems the alert dialog should tell the user where the log file was written, but I’m guessing some users might find a dialog that displays the path to their home directory, which might include their name or other personal info, to be somewhat invasive.

I’d like whatever approach I take to be acceptable for a commercial product, but other than that I’m looking for the simplest solution possible, more or less. What are other people doing? Any suggestions on what method to use?

#2

I think IMHO: better way: when user have crash is:
Show button “send crash report”, with field where hi can enter own email for back answer.
But it can be anonymous.

It’s easy - one click send and it can be anonymous – perfect for crash harvesting ^^

#3

The first question you should ask yourself is: what actual problem are you trying to solve?

Do you have an application, particularly a commercial product, that encounters a lot of unrecoverable errors? If so, the obvious solution is to, well, fix those errors. If not, then this seems a bit like solving a problem that isn’t actually a problem.

In “the real world”, generally you’d do a bunch of testing of any product before you ship it, thereby hopefully eliminating most unrecoverable errors before the customer can encounter them.

Of course, any product is going to have errors, and how you handle them really depends on exactly what those errors are. For example, some of our software requires certain data files to be in place. If those data files aren’t in place, we display a simple message to the user telling them to wait until we fix the problem on our end, and we provide a way for the users to email us from the application itself.

So the short answer is: it depends. The medium answer is: you should identify these potential errors ahead of time so they aren’t unrecoverable in the first place.

Other than that it’s really up to you. You might try to catch the error and show a simple message to the user, maybe with an optional stack trace they can send to you. If your context allows it, you might even automatically email that stack trace to yourself.

#4

Why not just send yourself an email…?

#5

I discussed this option in my post. If it turns out to be necessary to do it that way, I will, but in the meantime I’m just trying to avoid adding new items to my todo list and avoid adding additional libraries to the download.

Sure, that’s a good question, and I’m happy to clarify. The answer is that there should be no unrecoverable errors in the final product. Any such error would have to be e.g. a problem with the distribution or a previously undiscovered programming error. In other words, if things go as they should, the error handling code should never be executed. It’s simply there as a contingency in case something is missed during development and testing.

To rephrase the question then, given the above, is simply writing a log file to the user’s home directory and showing an alert dialog an acceptable solution? That’s what I’m doing currently, and I’m just wondering if it’s sufficient, or if a commercial app (even one that’s not expected to encounter unrecoverable errors) is generally expected to do something more sophisticated than that.

#6

I do anonymous error reporting from Headline Benchmark. I pop up a Swing dialog where the user can submit the stack trace and a brief description should they so choose. However, I have only ever had one error report!

#7

[quote=“Jesse,post:5,topic:54805”]
The golden rule in programming is that it depends on your exact context.

In other words, we can’t tell you whether a certain approach is an acceptable solution. That’s a conversation you have to have with your customer.

For example, say you have a little program meant to automatically push the “I’m Still Listening” button on Pandora. If that fails, it’s probably not a big deal, and you can display a simple error message to the user. On the other hand, if you have a program running the life support machines in a hospital, it’s probably a pretty big deal if that fails.

The point is, this depends entirely on the particular program, who your customer is, what their tolerances are, etc. There is no one-size-fits-all solution- some approaches will be overkill in some contexts, whereas they won’t be enough in other contexts. It really depends.

#8

Thanks for the reply, ags1. If simply writing a log file turns out to be unsuitable, I may end up doing something like that.

[quote=“KevinWorkman,post:7,topic:54805”]
Sure, I understand. Based on my experience on various forums I’ve found that people occasionally do have opinions about what features or behaviors they expect apps to have (or in some cases not to have), which can be informative. Or, it might be known in some cases that publishers will generally reject an app that lacks a certain feature. But, maybe that degree of certainty isn’t to be had here.

Just to clarify, my question wasn’t so much whether simply writing a log file is acceptable for my own purposes (which as you note only I can answer), but rather whether it’s ever an acceptable solution, generally speaking. If it is, that would save me some time, since it’s what I’m doing already.

In any case, thanks for your feedback - I appreciate it.