|Do you know where your variables are?|
However, one of the reasons I prefer exceptions to returning any sort of error object is because they act outside the normal return path.
The problem with "false == failure" is that it falls down as soon as you have "false" as a legal return value. For example, people often misuse read because it has different meanings for a false return value (0 == EOF, undef == error). People forget to check for the error condition - leading to nasty bugs.
The same sort of thing applies to any sort of "funny" return value - which in hindsight was why I was uncomfortable with the code I wrote in Test::Exception extension with (evil?) overloading :-)
With exceptions you don't have to worry about any confusion between legal return values and errors.
Another advantage of exceptions is that I can separate my error handling code from the error producing code, which makes things like massaging errors between different application tiers so much easier.
In reply to Re^2: Best Practices for Exception Handling (no isa)