I still maintain that the use of try and catch logic in Java (and where used, C++) makes programmers lazy. Having to check for error return codes at the point of the failure means the programmer will get in the habit of writing error recovery code.

Surely a developer no more "has" to check for error return codes than they "have" to check for exceptions. Indeed the opposite would seem to be the case since you have to catch exceptions if you want your code to run, while returned error values can be ignored.

I've seen tons of (and here is the key) badly written Java code that hits an exception and the whole program dies a horrible death with a stack trace, caught by some try/catch block that is not sufficiently fine grained.

I've seen tons of terrible C and Perl code that ignores the return values of system calls and falls over in really nasty ways when something goes wrong. To-may-to. To-mah-to.

I agree that you do get some terribly code in Java, but this is often due to the bad use of checked exceptions which many people, myself included, think are a bad idea.

I know, you are saying this is ok in Perl and is a good idiom -- I'm just saying, it's dangerous as heck and not conducive to error recovery. Error reporting and error recovery are different things, and the latter is a lost art.

I disagree. Indeed one of the huge advantages of exceptions for me is that they do allow you to separate error handling well. See Best Practices for Exception Handling for more in this vein.