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

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.




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

Search: