[jcrites]

This, and also the fact that once you've been maintaining an application for a short period of time, you quickly learn to recognize those "framework classes that are always there" in the stack trace and skip over them quickly. They are not really a burden, and as long as you're viewing the stack trace in an editor that responds to your mouse's scroll wheel it's no big deal.

I will agree with vbezhenar that Java stack traces are extremely useful. When something has gone wrong with an application in production, it is useful to know the call stack that led to the problem. I know that I didn't just fail in the method `Foo.doFoo()`, I failed in that method which was called by `Baz.doBaz()`. I know these two pieces of code are interacting which is a big clue as to the problem.

vbezhenar also offers good advice that logs of production software should be empty of exceptions and stack traces -- that the presence of anything is the sign of a problem, and thus rare in well-maintained software. Honestly, well-operating production software shouldn't emit any logs at all. Metrics and activity records if you need them, sure, but there's no need for logs. Logs can consequently be used to quickly pinpoint unexpected things happening.

[saiya-jin]

agree on mostly everything apart from last part - even well-working app should have some debug/info/warn statements. ie my current app - messaging integration tool build on apache camel, I log rather more than necessary, as messages go through various components, operations made on them etc. Each component isn't aware of others, so logging current state only if exception happens will lose some good info on overall situation happening.

a bit too verbose, but the amount of info I can get from UAT/PROD envs in case of an issue is mostly enough to fix the bug. verbosity can be solved easily by proper rolling & backup of logs, that's not rocket science.