Friends don't let friends do Java
teale.de
teale.de
Now, about the people that went on on to actually pile so many things on top of each other, just because they knew the language and tools were strong enough to let them do this up to a point... nothing good to be said.
But I've personally grown to admire languages and tools that give you enough high quality rope to hang yourself properly and thoroughly :) In the end, you can never blame the rope for the idiot hanged with it...
50 New Relic, 50 ActiveRecord, 100 ActiveSupport, 50 misc Rails / Rack, and 50 everything else.
This is not a Java problem.
https://github.com/rails/rails/blob/master/railties/lib/rail...
Perhaps you've disabled this? (FWIW, I don't mind the longer backtraces as they help in understanding thornier problems.)
It's not seeing a long backtrace that bothers me, it's the callstack being that deep to begin with. In my experience, it makes debugging slower and more difficult. If you're 30 calls deep, figuring out where you ended up in the wrong branch of a conditional is much easier than when you're 300 calls deep.
design for simplicity; add complexity only where you must.
Write simple parts connected by clean interfaces. [Kernighan-Plaguer]
Sure, in the old days, we had one giant function that did all the work, and we had a shallow stack.
But if your code is composed of simple methods that do just one thing, you'll end up with very deep stack traces.
Every modern framework has deep stack traces.
Yes, you need to invest some time in the beginning to understand how the different parts work together, but once you do, you'll see the beauty and clarity when all the abstractions are in the right places, and doing what you want requires just a handful of carefully sprinkled lines of business logic, with the framework doing much of the heavy lifting for you...
If a function runs on for more than a few lines, it feels like it rapidly becomes more difficult to reason about it. More mental overhead is required and more moving parts are in scope.
Long stack traces might mean you have to read more whole debugging, but it also means there is less code to debug for a given failure - assuming modularity!
Friends don't let friends use Tomcat/JBoss, Spring MVC, AOP Whatever, Hibernate and all that related crap.
Java is a big ecosystem. There's crap in it, as a consequence of it being big.
I have learned that when choosing a language to specialise in, you also choose the culture around it, which becomes very important when you live in it every day.
You could argue it's a consequence of well designed abstraction, though.
You're supposed to use the types `Option` and `Either` or if you're into scalaz then \/ (http://eed3si9n.com/learning-scalaz/Either.html) and Validation (http://eed3si9n.com/learning-scalaz/Validation.html). Throwing exceptions is a childish way to handle errors in FP.
Of course other languages have informative stacktraces as well, but IMHO Java has the most readable, complete and useful one.
[EDIT:] Actually this link should replace TFA, since TFA is a single image ripped from this link which has additional material to boot.