On Dec 28, 2013, at 11:27 AM, Cedric Greevey wrote: > > It helps to go with the "functional, immutable" flow, in which case if you > get an unwanted exception it should *usually* have bubbled up from some > failing test. Add a dump-locals where suggested by the stack trace and rerun > the failing test and voila! That should do it for almost all non-exogenous > exceptions, leaving mainly things like network timeouts and other wonkiness > caused by factors outside of your code (and, often, outside of your control > anyway).
You've given me some interesting things to think about re: the role of testing, but I think that it may be hard to map your approach directly on to the kind of work that I do. I often work with stochastic simulations which run for days and for which repeatability is hard to engineer, especially in a multicore context. There's a lot of unpredictable dynamism and usually code is generated and run dynamically (and mutated and recombined; this is "genetic programming"). Even if you code functionally and immutably (which I try to do, to a reasonable extent), and stamp out all nondeterminism (which would be a pain), it may take days to re-create a situation. So it'd be really nice if the system could just spit out more of the state that produced the exception in the first place, when it happens. -Lee -- -- 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.
