<p><strong>There is a lot of relativity involved in working with exceptions.</strong> Beyond low level APIs where exceptions cover errors raised from hardware and the OS there is a shady area where the programmer decides what constitutes an exception and what is a normal condition.</p>

<p>How do you decide when to use exceptions? <strong>Do you have a consistent policy regarding exceptions?</strong></p>

Exceptions are expensive in processing time, so they should only be thrown when something happens that really shouldn't happen in your app.
Sometimes you can predict what kind of things might happen and code to recover from them, in which case it is appropriate to throw and catch an exception, log and recover, then continue.  Otherwise they should just be used to handle the unexpected and exit gracefully, while capturing as much information as possible to help with debugging.
I'm a .NET developer, and for catch and throw, my approach is:
Only try/catch in public methods (in general; obviously if you are trapping for a specific error you would check for it there)
Only log in the UI layer right before suppressing the error and redirecting to an error page/form.