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.