> If you're not spending at least half your time on so-called 'error handling', you're probably doing something wrong, like using a language feature (like exceptions) to defer that technical debt to later -- and you'll regret it, if your project matures, I assure you.

Clarification please--are you suggesting the programmer can anticipate all reasonably likely error conditions and implement handlers for each?

I lean towards treating recoverable errors as uncommon, preferring a log->retry->give up strategy in most cases. The biggest sin is often in obfuscating the source error or prescribing a bogus resolution. Exceptions, while not perfect, remain a pretty good way to convey what was going on when things went sour.