This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I use two guidelines that give different answers in a bit of a balancing act:
Jeanne covered the first one: If you can't do anything with the exception, like retry the operation another way or do something else instead, just let it bubble up to the calling method. Don't code "catch, log, throw" unless you really add some value.
But! Don't expose your inner workings in the type of exception. For example if I have a data access interface that might be implemented with a database or flat files or calls to a remote partner system, I don't want the database version to throw SQLExceptions. I'd invent my own DataAccessException, catch any SQL or IO or whatever exceptions and throw only DataAccessException. That way the caller never needs to know whether I'm using a database or something else.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi