The most important thing to remember: exceptions must be exceptional!
There are several things missing in the answers above:
Yes, it's harder to ignore exceptions (compared to ignoring error returns). That doesn't stop entirely too many people from writing code that silently "swallows" exceptions, because they were (a) "impossible", (b) inconvenient, or (c) "I'll get to that later". That doesn't mean that error returns are bad, it means that bad coding is bad! (But we knew that!)
The business about "error returns can't return much info" is bogus. Most of what we return are objects. Objects can have all kinds of status information. In fact, they should -- "empty" or "zen" objects with status info is far, far better than returning 'null'.
Exceptions are noisy, and (in my experience of 50 years of coding) produce more code than the equivalent error return checks. Exceptions are also very, very, specific: every little thing that goes wrong gets its own exception. (And -- bad code again -- too many people wrap a whole bunch of different possible exceptions in a single try block... precisely because otherwise the code gets super "noisy".)
I'd rather (say) do an SQL query, get some results, and then ask "did something fail? What was it?" -- compared to (a) did I get an exception constructing the query, (b) did I get an exception binding the values to the query, (c) get an exception running the query, (d)... I forget. A well-designed object interface with an error return can tell me about any problems in one place -- instead of five.
Exceptions should not be used for control flow! And yet, that kind of code keeps getting written.
Many (admittedly older) library functions throw exceptions at the drop of a hat! One of the worst examples: Java's Integer.parseInt() throws an exception if its argument isn't a parseable number. Ye gods and little fishes! That's just nuts.