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.

Reputation: 2329

Exception handling architecture

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.

Upvotes: 14

Answers (4)

Rasmus Faber

Reputation: 49629

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

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

Upvotes: 6

Stu Mackellar

Reputation: 11638

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.

Upvotes: 0

Eoin Campbell

Reputation: 44268

.NET Specific but definitely has some worthwhile info.

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

Upvotes: 3

VonC

Reputation: 1324417

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)

Upvotes: 2

Exception handling architecture

Answers (4)

Related Questions