Exception handling architecture

Question

Does anybody have best practices for exception handling ?

When searching the web I find a lot of best practices on a code level (don't catch general exceptions, don't rethrow new exceptions etc.) What I am looking for is best practises on a higher level, stuff like :

• within an application catch exceptions on the ui level.
• log as much detail as possible, show friendly error messages
• in more SOA like apps distinguish between functional exceptions (You ask for a specific customer and expect to find one , but find none) and technical exceptions (database offline)
• don't use exceptions for functional exceptions
• distinguish between fatal and non-fatal exceptions
• distinguish between exceptions that make a retry possible or make retrying totally useless
• patterns for alerting the maintenance people

Any thoughts and help are greatly appreciated, thanks.

Answer 1

I like also to distinguish between:

• exception due to the caller of a function
• exception due to internal error within a function.

That is for me a clear way to separate:

• dynamic exception (that can occurs, but do not need to be explicity catched, liek an Illegal argument)
• static exception (that must be explicitly dealt with, because of a defect from the internals of the application)

Answer 2

.NET Specific but definitely has some worthwhile info.

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

Answer 3

A good article from Joel about exceptions (IMHO).

Answer 4

There is an article in Msdn library.

Answer 5

You could do a lot worse than look through the code and documentation for Microsoft's Exception Management Application Block. It's probably overkill for a lot of scenarios, but it's certainly comprehensive.

Answer 6

@Ilya:

That is probably one of the worst article Joel has ever written (for those who haven't read the link, he is arguing "Exceptions considered harmful", so do not use them).

Joel has two problems with exceptions:

1. They are invisible in the source code.

   • But so are unhandled status-returns. And properly handled status-returns clutter up the normal flow of the methods making them much harder to read.

2. They create too many possible exit points for a function.

   • And so what? Handling a failure will almost always require you to return early. Making the exit points explicit only serve to clutter up the code.

Ned Batchelder has an excellent (and much longer) reply to Joel here. Joel has a short reply here, to which Ned replies again here.

Brad Abrams also has a very nice article on the value of exceptions here.