Others experiences may vary, but mine look something like this. First, there is a stacktrace library that you need to use if you get runtime errors. This stack trace gives you line numbers and function names, so it's pretty easy to track the problem to the nearest named function.
From there, and for other errors, generally I use print debugging. Often times you can also just test a function in isolation on the REPL. This and the fact that you can hot-load code into a running process make print debugging tolerable.
There are fancier debugging tools in development for clojure, though I have no experience with them. Essentially they let you attach a REPL at arbitrary failure points. This would make it quite easy to identify the source of the problem.
Knowledge of the JVM does come up, but you won't be digging through compiled bytecode or the guts of java libraries (unless you use a lot of java library interop).
How does this compare to lisp, where you can break straight into editing code, inspecting variables, etc, and then continue?
This seems to be something Clojure really lacks, but I never see it explicitly stated in 'why you should use Clojure' articles, nor in Clojure books. What I want to read is a sober 'pros and cons of using Clojure' article, so I can properly judge whether I should switch.
From there, and for other errors, generally I use print debugging. Often times you can also just test a function in isolation on the REPL. This and the fact that you can hot-load code into a running process make print debugging tolerable.
There are fancier debugging tools in development for clojure, though I have no experience with them. Essentially they let you attach a REPL at arbitrary failure points. This would make it quite easy to identify the source of the problem.
Knowledge of the JVM does come up, but you won't be digging through compiled bytecode or the guts of java libraries (unless you use a lot of java library interop).