First of all let me stipulate that bad programmers are going to screw up. Whatever tool you give them. The essential problem here being the programmer, not the tool.

But with that said, in C no programmer can guarantee in complex code that error conditions are always checked. You claim that even novices know to do it. Perhaps. But even experienced programmers don't get every call right. And the resulting ignored exceptions are a persistent headache when dealing with large C applications.

As for the behaviour of Java programs that you dislike, that is 6 of one, and a half-dozen of the other. Depending on the context, you really do want errors to cause big, visible consequences so that they can be easily noticed and fixed. In other contexts you want to log it and show a prettier face. I've personally coded both behaviours at different times, and neither is intrinsically better than the other. In one errors are more visible. In the other they inevitably become more common.

However a personal tip. You claim to be both a young coder punk and old school in my software development practices. The tip is that one of the classic pitfalls for young coders with a lot of confidence is that they believe they can do it all. They can crank out tons of code, keeping 5 different things in mind, and get it right. Well, right after solving this one small bug, THEN it will be perfect.

It doesn't work that way. But lots of kids manage to seriously burn themselves out before realizing it...

First off, I'm hardly a "kid". Secondly, You've described the anti-me. I have the least tolerance for broken code as anyone in my organization, and "hammering out code" is the antithesis of everythign I stand for. I'm a design nut.

You used the tired "a bad programmer can screw up in every language" argument. Yes, very true... however the problem today is that new programming constructs (massive OO applications, EJB, SOAP) make it appealing and politically correct to do some very unmaintainable things. I've seen it happen. What's more, these practices are often encouraged without guarding the dangerous of over-indulgance. Some of these constructs allow interoperability between average level programmers in an organization (as is the case with massive OO), but there is a price. Sprawl. Chaos. Anti-Design in the long term. Perhaps not so in Perl as many of the Enterprise Class applications. "Enterprise Class" is usually implies "Massive OO construct with tons of exception handling", but these are also the inefficient error-prone beasts that consume 500MB of RAM. Attention to detail is lost when error checking is broad-based, and design is lost due to sprawl enabled by the lack of fine grained control and understanding.

I am not merely ranting on try/catch, but the concept of fine-grained versus coarse-grained error recovery. Your rebuttal to mine had some very excellent points, but the "kid" part wasn't one of them. Let's not judge based on percieved experience. Nixon* had plenty of experience. * = previous read "Nikon". That would have been funny.

I'm sorry for offending you by suggesting that you might be called a kid. If you read carefully, I didn't say that you were a kid, and in fact all that I know is that you describe yourself as a "young punk" and never meant to suggest otherwise. Also your impression of what I mean by "kid" might differ from mine. I tend to think of anyone below 25 as "kids".

As for describing you or anti-you, I have tried to describe neither. I have attempted to describe programming reality. Bugs are an inevitable fact of life. There are different strategies for dealing with them. The one strategy that I guarantee won't work is to believe that you can plan on consistently not making any given mistake. This isn't a question of tolerance or intolerance towards bugs. It is a statement of human limitations. Yet this is exactly the strategy that many try to make work.

About Enterprise Class applications. Mostly that means software created by and for bureaucracies. The development process involved inevitably guarantees a lot of poor trade-offs. The basic problem is fundamental to social organization, and not to any given development technique.

On fine-grained vs course-grained error recovery. Again it depends. I have seen people create complex error systems which become impractical nightmares to work with. I've also seen errors which are so uninformative that nothing useful happens.

Personally I lean towards a coarse-grained error system that gives you detailed information. See the comments on useful error messages in perlstyle. Add in a stacktrace with Carp. It only works with a certain range of applications, but that has proved to be of the ones that I have had to deal with.

OTOH fine-grained error systems are things that can be nice if your error system actually anticipates your actual problems. Of course that generally requires a level of advance planning that can easily go wrong. Managing complexity only sometimes means mirroring the complexity to be managed.

> that is 6 of one, and a half-dozen of the other.

Excuse the OT question but does anyone know why this cumbersome idiom is becoming so common in online forums? Whatever happened to apples and oranges, or simply "no that's different"?

Whatever happened to apples and oranges, or simply "no that's different"?

Nothing. But "six of one half dozen of the other" means "no difference", the opposite of "apples and oranges" and friends.

Bad Error Handling is just that, Bad Error Handling. Regardless of language and idiom.

The idea with exceptions is that you can easily (auto-magically as my old boss used to say) allow your error to pass back up the call chain to be handled appropriately. With error return codes, you have to pass that error back up the chain yourself, which can lead to an excessive amount of unnessecary coupling.

Don't blame the tool when the tool is used badly, blame the user.

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.

Well, open ... or die "open"; is the lazy way I think. It's easier than the same in C at least.