
 Vexing exceptions - prakash
http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-exceptions.aspx
======
jwilliams
This is good food for thought. When doing service design, I came up with three
levels that have some similarities - however - the main focus I had was on if
the client code can/should be expected to recover from the exception/error
condition.

1\. Execution of the method _failed_. The calling client code can't do
anything about it. For example, some system failed.

2\. Execution of the method _failed_ , but it's the fault of the calling
client. Again, at runtime the client can't be expected to recover.

3\. Execution of the method _succeeded_ , but not on the primary path. For
example, you asked for some data using and ID that no longer exists (e.g.
someone else transacted whilst you were). The calling client code could be
expected to take action to recover.

------
wayne
I think many developers believe they must avoid crashes at all costs and add
try/catch blocks to catch the Exception base class, which initially sounds
like a good idea but usually just hides subtle bugs which are 10x harder to
fix later.

This article does a great job of classifying exceptions and explaining when
you should, and shouldn't, add try/catch blocks.

