What should be included in the state-of-the-art error and exception handling strategy?

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?

1. When you have multiple developers, it should be easy to "hook into" your error handling framework, otherwise people won't use it.
2. 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.
3. 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?

1. 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.
2. 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).

1. From a user perspective, try to avoid errors by designing the interface in such a way that it is difficult for them to ma

It is important to get as much information as possible about errors that are occurring back to the development team. Log files are good in cases where there are no users to experice the error condition and you can be certain that someone is checking the log file. Automatic email is great for server based applications. Alert messages are problematic because users never read them. One trick that's worked for me is to copy a detailed error trace on to the clipboard while a user friendly error is displayed, then train users to paste the error trace into an email error report. The web equivalent is to display a friendly message while sending a detailed error in an email to the development team from the server.

There should be a log of last resort, in other words, what happens when writing to the log file causes an error? There should also be built in protection against "sorcerer's apprentice" type problems in which error handling itself locks the system up. On desktop systems, sloppy error handling code can result in a never ending cascade of message boxes that leave no option but to kill the app, possibly losing data in the process. Similar problems can result if error handling code triggers exceptions. The error handling framework should detect error handling errors and stop reporting errors if there is no better option.

For vital batch processes, nothing beats a proactive notification of success. If the "batch complete" email doesn't arrive, the user knows something's up, even if the error handling is fubar.

Exceptions should be caught at boundaries. All event handlers, public component functions, and service methods should catch all exceptions that occur. In some cases, re-throwing an exception makes sense; for example, when an exception is caught in a web service method, a SOAP exception should be thrown. But it is a bad idea to allow an excpetion to percolate across a component boundary automatically.

Conversely, it i

<opening my mind to new concepts>

• Chart the occuring error flow via analogue tickertape or earthquake monitoring roll printer, examine a weeks progress and compare it to historical data, usage data and compare it to preset goals. Temporary put the long printed long graph on the walls and bring progamming team together for a review. You buy their drinks, while explaining your question, this time very specifically, sothat programmers know for what you need a strategy exactly. I bet you that single coffebreak will yeald an effective and satisfying strategic answer to your question.

<closing my mind to new contepts>