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.

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.