Ha ha! I thought the only reasons could be laziness or ignorance, but deliberately skipping error handling as an optimization, that was new to me. Classic!

“My philosophy for Object Oriented: handle it “low” or handle it “high”, but nothing in the middle.”

For once I have to gently disagree with you. My philosophy is: Handle the error where it makes sence.
This usually means handling it “low” or “high” (in fact more often high, in the GUI layer), but not always. It happens sometimes that I find situations where it makes sence to handle errors in the middle tire.

“don’t throw an error if some other return value is also appropriate”

The thing here is not to mute information about an error that could help identifing problems. A return value can only tell you OK, or NOT OK but nothing more. This is fine for really low level functions (like malloc) but should be avoided otherwise.

But! If we’re not talking about an actual error, like for instance a search that resulted in no hits, then of course a return value is the correct way to handle it. Exceptions should not be used for anything other than exceptional (invalid) program states.

My philosophy for Object Oriented: handle it “low” or handle it “high”, but nothing in the middle. That is, either catch the error right away and do something useful with it, or allow it to propagate up to one big general error handler and have it dealt with there. Also, don’t throw an error if some other return value is also appropriate, e.g., return null or an empty list instead (and in-band signal like -1 is also appropriate).

Paul.