Would there be interest in a ticket in this? Seems simple enough if (as above) putting the message under the :pre key is acceptable?
On Thursday, July 14, 2011 at 3:25:16 AM UTC+12, frye wrote: > > I do think a simple String error message is all that the user of the > function should provide. From there, An AssertionError can throw up > something along the lines of what you said - Expected… , Found… , Message. > That would give enough information for reporting at least in a test > framework. To get more precise information, like you said, that > AssertionError could also throw up class/file information, etc. that a > debugger could use. I would guard against designing these things to > accomodate a context outside of it's execution scope. In the ideal > functional world, the input and output are wholly localized. Any > Error/Exception thrown can be consumed or chained to give very precise > failure reasoning. > > > As for how that would fit into the entire exception chain, that's still > being thought (see here > <http://dev.clojure.org/display/design/Error+Handling>). There are > already a few approaches, and I think this (see here > <http://dev.clojure.org/display/design/Error+Handling+Comparisons>) is > the context of how the core team is approaching this problem. > > > Cheers > Tim > > > On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar <kumar.s...@gmail.com > <javascript:>> wrote: > >> As I am the culprit of having introduced it with a naive example, I'd >> better admit it may not be very useful in practical scenarios across a >> wide variety of use cases. For example, when there is an assertion >> error with message "`m` should be a map" 14 levels down the stack, I'd >> really wish it said "`m` -- Expected: map, Found: vector [:foo :bar]" >> so that I can debug it quickly. >> >> Pre-conditions and Post-conditions are a valuable debugging aid, and >> to enable that we need very precise information. Unfortunately passing >> a string error message cannot encapsulate enough error context. A more >> complex example can be where the correctness of input must be >> determined collectively (in association with other args) -- in those >> cases one can only fall back on comparing input values and raise >> IllegalArgumentException accordingly. >> >> Regards, >> Shantanu >> >> On Jul 11, 10:40 pm, Timothy Washington <twash...@gmail.com> wrote: >> > >> > > -- 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/d/optout.
