Hacker News Reader

Comment by geokon | Hacker News Reader

Could `scope-capture` be used to capture state before a crash?

What would be nice is a GDB-like state along with stacktraces when you get a crash. Clojure stack traces are notoriously long and spooky. You learn to read the tea leaves, but even if you manage to identify where the crash happened and what triggered it (not always obvious..) you then need to pepper things with `println` to figure out the last local state before the whole thing blew up.

It looks like once you've found the problem area you can use `sc.api/spy` ..? It'd at least solve half the problem

View on HN

I find the stack traces to be fine as long as there's some middleware in use to filter out the Java stack frames from non-Clojure code, like eg CIDER does (and probably other envs can too). Otherwise they have some noise which is a bit annoying but not showstopper.

println (or other logging/tracing, eg using tap) works for seeing where things go wrong, but stepping through code with a debugger works too if you're so inclined, or experimeting at the repl.

Sure, it's not always obvious what caused bad input that evnetually leads to an uncaught exception, just like in other languages.. it might have come through an event loop or other layer of indirection that doesn't show the real caller, for example.

right, it's not like you're completely stuck with no way to figure out what's causing your problems. In pretty much every language you can get a crash stack and pepper print/logging statements. And sure, the Clojure stacks aren't always impenetrable (unless it's blowing up in some call back or lazy evaluation.. then good luck). But I don't think it should be brushed under the rug that that the debug situation in Clojure is problematic.. and it's behind ancient creaking languages like Elisp and the much laughed at C++. The REPL is great for sure, and it makes punching out code much faster, but when you need to debug some deep problem I start to miss GDB a bit :)

Next time I'm in a bind I'll have to try `scope-capture`. It looks like it might get me half way there

Valid point about laziness, it can make for head scratchy stack traces. A debugger works well for that as well. I think the lazy by default behaviour of many things in the stdlib is a questionable design decision, and try to use eager versions of functions my default (eg mapv and filterv).

Assuming the crash doesn't cause the process to completely exit, you could indeed use `scope-capture` for this. This works well for local dev. In theory, you could use `sc.api/spy` in production code, and then attach a remote repl to diagnose any crashes. I wouldn't recommend this though, I think it would be best to use a good logging library like Mulog: https://github.com/BrunoBonacci/mulog

Right, if you're doing web-tech stuff and have servers then this seems the right way to go. I'm usually more interested in local REPL development. I will have like GUIs and whatnot blow up on me. But I appreciate the info and the post

Reply on news.ycombinator.com