I have some apps on my Windows Phone that crash every day the first time I open the app. They get their crashing over with then for the rest of the day I'm good and I can use the app. These aren't minor apps either; I'm talking about Windows Phone marketing material apps that crash on errors. I think that's crazy. Being an avid user and supporter of the Windows Phone platform I want it to succeed and I want to be a part of that success. I also know what bugs me when I use my phone. The Windows Phone user in me really gives me an advantage as a developer for the platform.
Error handling is that thing that everyone hates to do and is always a second or third thought when it comes to application development. I think it's just easier to say “you're screwed” if you get in this state so we don't even handle it, or maybe we don't know how to recover gracefully from the problem.
What if we thought of error handling as a feature of the app?
What if intelligent error handling was something you could list as a selling point of the app? What would your error handling look like if you took the time to come up with a plan for it?
If we did this, I'd like to think that the application would try to help you with the problem, even if the app can't solve the problem for you. That feature should give as much helpful information about the problem as possible (even if they are guesses) and maybe even a way to get more help if that doesn't work. That's a smart app!
Well it turns out this method of app error handling is starting to catch on. I've noticed a few apps trying to catch general exceptions and tell the user that terrible things happened and you need to restart your application or to try again later. Some of the better ones will even let you email the error to the developers and gracefully continue the application.
As you implement this for your own apps, you need to be careful though. Emailing call stacks should be a last resort. You could be leading the user into thinking they are giving you personal information by helping you identify the problem. We know that's not really the case, but a common user may feel this way. So what's the compromise? I don't know… but I can tell you what I did.
Development on Yinzlate went great. I didn't have any real problems until a day or two before I wanted to submit. It wasn't until I started edge cases. The only exception that I wasn't handling by correcting the input was related to the speech recognition. While the speech recognition is fantastic on Windows Phone, it certainly does have its odd problems that I ran into. For example, speech recognition and speech synthesis (playback) is not supported for all supported languages on the phone. It's weird to say that but there are some languages that just don't support interpreting your spoken word. Now, I never intended to support multiple languages in Yinzlate, but I at least need to prevent the problem. Here is the problem I was getting after having the required English language installed but having my default language as Russian.
SPERR_WINRT_UNSUPPORTED_LANG 0x800455BC The requested language is not supported.
I could only find this description in the HResult of the Exception class, but that is enough. I know what is going on every time the user hits this problem and I can tell them how to fix the problem. I can't fix it for them, but I can give them instructions on how to get it working.
Think for a moment about what the result would be if I didn't handle this exception. Someone would download Yinzlate, push the button on the first page which would crash the app. They would immediately assume the app is just bad and uninstall it when in fact it wasn't even Yinzlate's fault. You're not using a supported language for the features the phone provides. We know enough about the problem to prevent it. So why not tell the user the problem.
Only after we exhaust all possible known problems should you fall back to just sending a call stack. When you send it, try to make them feel a little bit better about it.
More importantly, follow up on it if they do decide to send the email. Either your users want to make your application better, or they are terribly frustrated and want corrections bad enough to put themselves out there a bit and send you an email. Repay the favor and get it corrected. When you do, send them a message back saying you addressed it.
My wife recently reported a problem to an application that gave her the opportunity to email the call stack. The developer(s) corrected the problem and sent her an email back saying it was corrected and would be available in the next update. She was so happy to receive that connection with the developers that it really dulls the pain of the original problem.
I think it's important to point out that I'm using exception handling like this in locations that I know have a potential to fail. These are mostly around the phone's capabilities. I once knew a developer that would wrap all of their code in a try/catch just in case something went wrong they could gracefully fail by doing nothing. Yinzlate is an entertainment app. We're not launching missiles or doing laser surgery. It's OK to have an unhandled exception and crash if it's truly something you can't handle. Maybe it wasn't even your app's fault. If you're using the dev center app to track downloads and crashes, allowing unhandled exceptions is a great way to gauge the true health of your application. If you are handling every exception and people are not sending you notifications about errors, how will you know you have a problem?