Why are Clojure stacktraces so long?

Question

I\'ve written some toy interpreters/compilers in the past, so I associate stacktraces referencing lines in compiler source files with compiler bugs.

If I add the followi

Answer 1

Replying to your numbered points,

1. it is idiomatic in Clojure to interoperate directly with Java libraries, so getting the full Java stacktrace can be helpful if you are calling into Java objects in some unexpected or unsupported way.

2. Sounds like a good idea; I've often at least wished for a settable option which would allow me to see only the parts of stacktraces originating in my own code, suppressing all the underlying language layers.

3. I usually just do it the hard way and pore over the stacktrace to get the line in my program that barfed, tuning out the clojure.* parts (and I usually test each minute change so I have a pretty good idea what change caused the problem). Some of the Emacs and Eclipse tools I've used show you only the actual error and not the whole stacktrace; I generally find this to be more helpful.

   At Clojure/west in 2012, @chouser gave a nice talk [PDF] on the anatomy of stacktraces, explained how to read them, and introduced a promising-looking tool, which apparently still has not seen the light of day yet.

Compared with, say, Python, whose stacktraces I find pretty user-friendly, I think stacktraces are a rough edge in Clojure, particularly for beginners. This is partly due to the "hosted" nature of the language, though I expect there are improvements which could be made without adding incidental complexity.