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

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