Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What’s bad about Java stacktraces?


The problem is that the stacktrace shows you all the gory JVM details that are irrelevant to your Clojure code. Even when your code is 100% Clojure, the Java classes, that are the foundation for Clojure, are shining through when you get the stacktrace.

It's been a while since I last used Clojure, so I don't know if the situation has improved in the meantime.


For what it’s worth, it’s very easy to filter stack traces in most Clojure tooling. You don’t have to look at anything but your code, or just Clojure code etc. Obviously you’re still looking at Java exceptions for the most part, but I’ve never found being on top of the JVM as icky as some others obviously do.


Even such a filter is too often useless. Like, 4 out of 5 times. I rely more on logging and parameter inspection. E.g.:

  (defn foo [a b]
    (def a a)
    (def b b)
    (/ a b))
If the function fails, I have captured its input parameters right before the exception occurred and now I can inspect it from the REPL if 'b' is 0. From the REPL I can change the value of 'b' with simple `(def b 42)` or change the very definition of 'foo' and re-evaluate it again on the REPL with simple `(foo a b)`.

I even made myself an elisp function for inserting the '(def a a)' into the code https://github.com/Bost/corona_cases/blob/master/.dir-locals... (enjoy).


Would CIDER's interactive debugger not be more straightforward here?


That's not an IDE agnostic approach. IIRC after modifying and reevaluating the function inside which the debugger is currently in, the debug session is terminated and the evaluation context i.e. the values of input parameters are lost. Even if the session can be restored I'm not sure if it survives a REPL restart. And even if it does I'm not sure if it survives a reboot, unlike my approach.

Moreover, this approach with defs allows you to inspect every function, even those macro generated. And if committed, such a "debug session" is persistent across every instance where the code is deployed, from any development machine, through all test and staging machines right into production. (So when combined with some remote REPL access... you see what I mean?)

Another thing is that I like when my code strongly express the notion of compositionality, i.e. when it looks something like this:

  (comp
     ...
     (partial map ...)
     foo3
     (partial reduce ...)
     (fn [p] (def s3 p) p)
     (partial map ...)
     (fn [p] (def s2 p) p)
     (partial apply ...)
     (partial map ...)
     foo2
     (fn [p] (def s1 p) p)
     foo1
     (partial apply ...)
     (partial map ...))
here I introduce and comment in/out the '(fn [p] ...)' expressions as needed. That kills two birds with one stone. 's1' captures the output of 'foo1' which is also the input of 'foo2' at the same time.


It did improve, but you still can get those from time to time.


The unfortunate side effect of such improvements is that when the time comes you do get to peak at the details you’re in unfamiliar territory.


strict answer: they are very deep.

informal coffee break answer: abstracted layers of abstracted abstraction within parametrized abstractions just don't feel right to lispers.


FYI you're writing this post on a device which is a product of millions of ideas and inventions all of them refined, abstracted and parametrized thousands of times, if not even more.


Have you ever seen Java/Clojure stacks? :-)

My browser is cpp program. Say, 10 layers are typical. Then, there's a libc + ui linux code. Usually in c, so even less layers. Say, 10 more. Then, there are sycalls annoying the kernel from time to time. Pretty shallow, btw, 5.

That's 30 roughly speaking. Maybe 40.

Java + clojure combo is not impressed, not at all.


The page count




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: