I'm currently in the thick of managing and building the next release of our proprietary internal line-of-business application which I'll call LOBAPP. It's always interesting to see what problems are discovered once acceptance testing begins.
It's challenging to maintain multiple development and test environments, and the personnel that keep everything running aren't under my control- they are motivated mainly because I'm such a nice guy. As LOBAPP has grown, it has unfortunately developed a few 'uninsulated' dependencies. By uninsulated I mean that the dependencies aren't hidden away behind a facade or a dependency injection container where their absence won't destabilize LOBAPP. Yes, I know, bad design, etc., but this is real life and we are dealing with it incrementally.
The point I want to make, though, is about what happens when certain external dependencies aren't available: LOBAPP displays a really ugly error report to the user then closes. Ugh. The app is dying violently instead of gracefully and with dignity.
Unless the exception is completely unhandled, you should make every attempt to tell the user what is happening. You don't need to display to them all of the gory details- in fact, this could be a major security risk- but the user interface should inform the user that something has gone wrong and that someone is being notified of the problem. Their work has already been interrupted so why aggravate and antagonize them more by abruptly crashing with only a witches' brew of technical mumbo jumbo as a farewell from the dying application?
Monday, October 4, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment