Design patterns: exception / error handling

Is there any resource (web or book) describing exception handling / error handling design patterns?

There is a lot of literature on how to write clean code, and there are a lot of books covering design patterns. I have, however, never seen any design pattern covering the issue of where and how best to handle errors and how best to propagate an error appearing in a low-level function up the levels of abstraction.

57640 次浏览
小开
最佳答案

These patterns and best practices are often bound to a specific platform/language, so they are the first place to look for them.

As an example check the following links for java:

Going through such materials would give you a general idea to follow in exception handling mechanisms.

Also check other SO questions:

小开

Best approach is never to swallow any exceptions within your application code. Hookup a handler to unhandled exceptions in your applications when bootstrapping where you can show an error message and do some logging.

Some decent books i've read recommended this approach.

http://thibautvs.com/blog/?p=2238 is a good one where it's mentioned.

小开

Description of using exceptions on .NET (but not only) in details: http://msdn.microsoft.com/en-gb/library/5b2yeyab(v=vs.100).aspx

When one should use them, how to write them, how to handle them correctly and so forth...

小开

Because this question is about design patterns. I'd there is not one pattern but two.

  1. Observer Pattern
  2. Decorator Pattern

Generally a try/catch/finally block is written for handling exception which could go terribly wrong very soon. If you are logging exception in catch block you have got it wrong already. If you are trying to recover from the exception and continuing the code flow then you are right. If you didn't expect the exception and chose to ignore then you are doing the right thing.

Also, who do you write exception handler for. There are at least 3 audience of an exception.

  1. The end user. The end user wants to know what went wrong and what he is supposed to do next.
  2. The support team. When the end user reaches out the support team is supposed to give him a satisfactory answer.
  3. Finally third, us, the developers. We would want to know what were the variables/function/stack trace when the crash happened. So that we can diagnose and make fixes.

There could definitely be more parties interested in the exception but at least these three.

All these audience have separate exception handling requirements. User wants to a see a friendly message, support wants to know next steps. and developers wants to see stack traces for fixing it.

This makes exception not a single function but a series of event handlers. One for each participant (Observer pattern).

Because we follow DRY principles we don't want to repeat the try/catch/finally block in all the functions. So we write a decorator class. This class is an implementation of Aspect Oriented Programming (AOP).

One generic class that is decorating all the class (from specific assembly at boundary of application) using reflection. And one single try/catch/finally block inside decorator to take care of the th


提交答案