You have production code going *boom* that doesn't have any failing tests? Or you have nondeterministic tests? :)
On Tue, May 28, 2013 at 1:49 AM, Mark Engelberg <mark.engelb...@gmail.com>wrote: > On Mon, May 27, 2013 at 10:25 PM, Cedric Greevey <cgree...@gmail.com>wrote: > >> What about add-watch? Can be used with any of Clojure's mutable-value >> containers -- atoms, refs, agents, vars. If one is getting set to an >> inappropriate value, or you suspect it is, you can attach a watcher to it >> that will emit a log entry anytime it gets set to a value outside its >> expected range, including printing a stack trace that should include the >> spot in the code where this happened. >> >> In the case of immutable data or mutable Java objects getting scrozzled, >> there's always the option of modifying the possible sites of the trouble to >> log buggy behavior. For instance, if a LinkedBlockingQueue is getting >> polluted with nils that are making the consumer blow up, adding before >> (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.))) >> will move the blowup closer to the actual site of the error and give you an >> informative stack trace. You might even leave that one in in production, if >> the thing should (or *will*) die anyway if a nil gets in there, so your >> user base's bug reports will already have a useful stack trace instead of a >> useless one. >> >> Bad function arguments? Add a :pre clause to blow up immediately with a >> useful stack trace, if one otherwise doesn't show up or shows up far from >> the error. Bad values getting into immutable data? Add a (print ...) >> wherever it's built up using assoc or conj or what-have-you. >> >> >> > > You've just listed three things that I can *add* to my code to track down > errors: watches, logging, pre clauses (and let's not forget the old standby > printf). But that all misses the point. When my code goes *boom* and I > get an error and a stacktrace, I want to know specifically what the context > was at the time of *that particular crash*. If I have to alter my code and > rerun, it may be hard to recreate the conditions that caused the error. If > the stacktrace simply revealed richer information, such as what the inputs > were to the various functions in the stacktrace, and I could explore the > local variables, that would save tons of time spent trying to annotate the > function to print or log the variables and then trying to get the bug to > happen again. > > -- > -- > 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. > > > -- -- 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.
