I'm not sure what your point is. I rely quite a bit on randomly generated tests, and of course, any multithreaded app has nondeterministic elements that can be hard to replicate.
For that matter, if you are simply experimenting with new code at the REPL, it might not always be clear what sequence of actions brought about the unique state that caused the problem. Even if it is clear how to recreate the problem, it can be tedious to annotate the code with extra logging info to print out all the local variables, and the mere act of doing so might make the problem go away. There are all sorts of reasons why you'd want to do a fuller investigation of a crash when it happens, using information that was generated directly by the crash, without having to add new code and reconstruct the events leading to the crash. On Mon, May 27, 2013 at 10:53 PM, Cedric Greevey <cgree...@gmail.com> wrote: > You have production code going *boom* that doesn't have any failing tests? > Or you have nondeterministic tests? :) > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
