Others may have to correct/clarify this, but there's a strategy called (I believe) "contract-driven development", where you explicitly document in your public interface what the expected preconditions are for each method, and the guaranteed post-conditions. Then, when implementing the method, any error which prevents you from meeting the post-conditions in the contract should result in a thrown exception. Failure to meet preconditions is considered a program error and should cause the program to abort.
I'm not sure if contract-driven development speaks to the question of catching exceptions, but in general you should only catch exceptions that you expect and can reasonably recover from. For instance, most code cannot meaningfully recover from an Out Of Memory exception, so there is no point in catching it. On the other hand, if you are trying to open a file for writing, you can (and should) handle the case that the file is exclusively locked by another process, or the case that the file has been deleted (even if you checked its existence before trying to open it).
As noted by another commenter, you should also avoid using exceptions to handle expected conditions that can be expected and avoided. For instance, in the .NET framework, int.TryParse is preferable to int.Parse with a try/catch, especially when used in a loop or such.
