I think the art of exception management is knowing where to use try-catch blocks. Over the last couple of years I find myself using less and less of them and now tend to place them only in the top level consumer classes (of course there are always exceptions).
I am more concerned with throwing exceptions as a way of tranferring information about an error condition. If an exception isn't thrown then the caller has to check for an error condition after the method call has returned. The latter can get onerous especially
when the mechanism to check for error conditions varies across different modules. Exceptions present a standard way to transfer the error details and have the added benefit that they can be allowed to bubble up if the caller doesn't want to handle them.
From the msdn chapter referenced by spod one of the guidelines for exceptions is:
"Do not use exceptions to control application flow"
The reason being that exceptions are expensive. However exceptions make the code much more intuitive and the .Net base class libraries seem to ignore the guideline. I wonder if it really is that expensive in a "typical" managed application?