There are so many possible answers here, but I'll take a crack at it.
What issues should an application designer take into consideration when devising the error and exception handling strategy?
- When you have multiple developers, it should be easy to "hook into" your error handling framework, otherwise people won't use it.
- Use transactions wisely to maintain data consistency. I see apps all the time where a failure could occur halfway through a process and cause wierd data inconsistencies because the entire operation was not rolled back properly.
- Consider criticality when you handle exceptions. For example, if you have an online ordering system and part of that workflow is to have an e-mail sent to the site owner letting them know that a new order was placed. If sending that e-mail were to fail, should the user get an error and the whole order be cancelled?
How the strategy will differ depending on the software type (COTS, in-house business app, consultingware, game, hosted web app, embedded etc)? Is the software type important?
- For desktop type or embedded apps, recording information about the environment (os version, hardware, other apps running, etc) can be very useful when investigating error reports.
- For enterprise apps and web apps, things like e-mail error notifications, SMS messaging and integration with ECO tools (e.g. Tivoli) become very useful.
Ethical, political and legal issues?
The only thing I can think of here would be for desktop apps - "phone home" type applications are generally frowned upon, especially if they submit information about the users machine that could be sensitive.
Various perspectives on error handling (user, developer, business support, management).
From a user perspective, try to avoid errors by designing the interface in such a way that it is difficult for them to make mistakes. Don't ask questions that the user probably won't be able to answer (Abort, Retry, Fail anyone?)
From a developer perspective, you'll want as much information as possible to help diagnose what happened - stack trace, environment info, etc.
From a business support & management standpoint, they'll want to know what to do about the error (mostly in an enterprise environment) - who is responsible for the application (who do I call/page/etc?) as well as the criticality and any possible side effects (e.g. if this batch job fails, what business processes will that affect?). Written documentation is your friend here.
