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

Question

I understand that this is a very broad question, but a short “it depends” kind of answer will not be accepted. Strategies are born to deal with broad issues.

1. What issues should an application designer take into consideration when devising the error and exception handling strategy?

2. 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?

3. Ethical, political and legal issues?

4. Various perspectives on error handling (user, developer, business support, management).

Some ideas that I would have explored:

• Various error reporting routes (i.e. UI, logging, automatic admin notification).

• Defence in depth and robustness (failover contingency and fail-safe mechanisms, recovery against problems that are not yet known).

• Treating users and customers fairly (i.e. minimising the impact on software users and other people serviced by software).

I'm looking for a similar list of ideas and concepts.

Please do use comments to point me out if I need to clarify the question further and thanks to everyone contributing!

---

FAQ

Development Platform (Java, .NET, mobile) — will definitely have some affect on the resulting implementation detail of the strategy from a developer perspective but less so from users' point of view.

Fools day it is certainly not. Most legacy systems I was asked to work on did not have a clear error handling strategy.

Could this be made a community wiki? No. It seems as a good question and good questions are hard to come up with.

What do you mean by the strategy? A long term plan that gives direction, focus, brings consistency and coordination to error and exception handling. In case of a larger team working on software the strategy can be formilised and distributed in a written form.

It seems to be duplicate question (see Best practices for exception management in Java or C and Which and why do you prefer exceptions or return codes) These questions deal with a certain perspective on error handling (mostly developer), I'd like to learn more about other perspectives and how they contribute to the overall strategy.

Answer 1

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 make mistakes. Don't ask questions that the user probably won't be able to answer (Abort, Retry, Fail anyone?)

2. From a developer perspective, you'll want as much information as possible to help diagnose what happened - stack trace, environment info, etc.

3. 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.

Answer 2

I'm coming from a Java background, but my response should apply to .Net, as well.

Rules of thumb:

1. Write your code to fail fast: Hunt & Thomas; Tip 33
2. Test all of your parameters with a param check library - these are not exceptional conditions. They are misuse of the (documented) API. Example: google collections Predicates
3. Use Exceptions for exceptional conditions: [Hunt & Thomas]; Tip 34. Exceptions should NOT be used as return codes.
4. Test for exceptional conditions: Exceptions are postconditions for method invokations. If you can't get there with a test, the Exception shouldn't be declared.
5. (For Java) Follow Josh Bloch's advice (all of Chapter 9). Some important tips: 5a. Throw exceptions appropriate to the abstraction. 5b. Strive for failure atomicity. 5c. Include failure-capture information in the detail message (or encapsulate it in the Exception itself). 5d. Don't ignore Exceptions.