Reacting to Exceptions

While preparing my slides for the Community Tech Days at Kolkata, I encountered a very interesting exceptional situation. Just to sync you up, I was evaluating Office 2010, specifically PowerPoint 2010. The very first slide had an effect exclusive to the 2010 version of PowerPoint. Just to check the compatibility I ran the slides on another system with PowerPoint 2007 version installed. To my amazement, the slides ran without any effects. No messages or warnings whatsoever! I went berserk (and FYI when I go berserk, that ends up into a new blog post).

The immediate question that spring up was: shouldn’t PowerPoint protest about missing effects? Should it just skip the problem-causing effect, and continue with the show (and prove itself to be robust) or at least caution the user about something that did go wrong at execution or runtime? This spawns up a simple yet important question for us developers: how should we react to exceptions that we don’t predominantly expect and when should we completely disregard them?

Missing effects in a PowerPoint show is surely not a consistent exception. In my personal view (and that’s what this blog is all about), the Office team has full rights to expect a v12 presentation to be opened with v12 of PowerPoint. When I ship an app’s v2 version and supposedly I have a custom document type registered with my application (say .vaibhav or .vaibhavx, to better match the document format trends), I surely would expect a v2 file to be opened by v2 of my app. If the user attempts to open my custom document with an earlier version, I would simply penalize the user for not using the most recent version of my app by throwing an exception, and maybe (I do this for fun) shutting the application. This, I believe is a common trail that most (if not all) of us take when determining on similar problems (saves time and heaps of code, trust me). But then, where exactly does app compatibility fit in?

Software is backwards or downwards compatible when it can work with input generated by an older version. If software designed for the new standard can receive, read, view or play older standards or formats, then the software is said to be backwards-compatible. Forward compatibility or upwards compatibility (sometimes confused with extensibility) is the ability of software to gracefully accept input intended for later versions of itself. The introduction of a forward compatible software technology implies that old software partly can understand data generated by new version of itself. A forward-compatible system is expected to "gracefully" handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling. Forward compatibility is harder to achieve than backward compatibility because a system needs to cope gracefully with an unknown future data format or requests for unknown future features.

The keyword above (for me at least) is graceful. But, should I leave the user in an indecisive status by removing the obtrusive exception messages? Will that tantamount to a tolerable UX (user experience)? Wouldn’t it be better if I could inform the user, what the problem was, and what its probable solution would (could) be?

How would you resolve a similar situation?

And in the meantime, let me continue to discipline my users with beautiful dialog boxes with subsequent calls to Application.Exit()

Happy Coding!