Using Exceptions, good or bad?!

Last year when I started to discuss this matter with my friends, I was almost sure that they all love exceptions, but I've found out that I was wrong! So lets could be the drawback of the exceptions and shall we use them or not.

First, lets say an exception is like a sword. You can use it when something happens to protect your code from unwanted results, but at the same time cut you if someone throws it and no one catch it.
Also, no one will use a sword to peel an apple! will you?! :D

Advantages
Well, I myself cannot imagine how hard it would be to write a clean code without exceptions. :) You will prevent unwanted effects with only one line of code. There is no need to return message, value, etc. it could be logged very easily and your log can contain every detail that you may need. specially the call stack! By using typed exceptions (who won't?!) you can choose different reactions and by using inheritance, you can have even more control.

Disadvantages
handling lots of exceptions is hard. You have to have a good idea about what is going on in your project. As I said, it is a sword, if you use it in a small code, like throwing an exception and handling it inside a class (or even worst - inside a method :| )
If you don't know what you are doing, you will most probably end up with a very ugly code that will be very hard to maintain

Where to throw an exception

An exception has to be thrown in these cases:
1- When there is a special situation in your code.
Think of normal scenarios that you've seen until now, like when memory is not accessible, network is down or etc. These situations have a meaning in their criteria, but at the same time they will tell make the user (code) to handle them properly.It is important to notice that it is not only connected to a low level code, when your code is about bank accounts you can have exceptions like "the balance cannot be negative" or "insufficient funds", etc. or for a method that handles shipment it can be "Product already shipped" or "The stock is empty", etc.

2- Where your domain ends as a wrapper
Basically speaking, you may need to have lots of different events in your code, but in many cases you don't want to return the complete details to the one who consumes your methods/services/package. For instance, you may have different rules in a banking system that you need to manage internally, but when there is a relation to other system, it just needs to know that an exception from "Specific Type" happened, and maybe a message and a code for the reference, there is no need for additional data.

Where to handle Exceptions
Well this one is obvious when you know the first part,
Of course on any outer edge of your domain/service you can decide if you want to take an action on your specific exceptions. If you have created an exception to stop the whole system, then you have to let it go, otherwise you have to handle the exception and take a suitable action.
A long sword can only handled by a strong man while even a girl can handle a short and light sword.

Also, if you are interacting with a human, you have to make sure that no exception reaches him. You just need some messages as a hint/error for the customer, and nothing more.