14

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.

S.Lott
  • 384,516
  • 81
  • 508
  • 779
KeesDijk
  • 2,299
  • 1
  • 24
  • 37

4 Answers4

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.

Rasmus Faber
  • 48,631
  • 24
  • 141
  • 189
  • From this link is a link to http://nedbatchelder.com/text/exceptions-in-the-rainforest.html, which is a nice beginning for what I am looking for. Thanks – KeesDijk Oct 28 '08 at 10:40
  • I'm a C person and don't like the idea to work without goto as well. So I'm not completely agree with Joel, but he definitely has a point. And article is relevant at least for the reason that it's give you another point of view and for me possibility to read reply article as you mentioned. – Ilya Oct 28 '08 at 10:50
  • Actually after reading the replay i was not convinced. But i don't want to start theoretical discussion here. – Ilya Oct 28 '08 at 10:55
  • So your point is only that you're too lazy to code properly, so let's just use exceptions? – Pablo Ariel Jan 21 '14 at 14:22
  • @Pablo Ariel: No, that is not my point. Did you even read what I wrote? – Rasmus Faber Jan 21 '14 at 19:06
  • Actually I find error handling code to be quite verbose about what's the code doing and why it failed. Also handling a failure is the only way to make the program work properly after failure. Both times you mention that the problem of return values as errors are just that you have to make an effort to read them or write them and by using exceptions you just don't have to care about anything error-related. – Pablo Ariel Jan 22 '14 at 17:22
3

.NET Specific but definitely has some worthwhile info.

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

Eoin Campbell
  • 43,500
  • 17
  • 101
  • 157
2

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)
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

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.

Stu Mackellar
  • 11,510
  • 1
  • 38
  • 59
  • It took me some time to look at this and it has some interesting things in it. But it is still to low-level and a bit old. Thanks for the effort – KeesDijk Oct 28 '08 at 13:39
  • 1
    Another look reveals that it's been updated more recently (October 2008) as part of the wider-ranging Enterprise Library. http://msdn.microsoft.com/en-gb/library/cc467894.aspx – Stu – Stu Mackellar Oct 28 '08 at 15:09