A wonderful hack I read about somewhere is to just use the clojure.test/is macro, which I now do all the time:
(require '[clojure.test :refer [is]]) => nil (defn get-key [m k] {:pre [(is (map? m) "m is not a map!")]} (m k)) => #'user/get-key (get-key [] 0) FAIL in clojure.lang.PersistentList$EmptyList@1 (form-init8401797809408331100.clj:2) m is not a map! expected: (map? m) actual: (not (map? [])) AssertionError Assert failed: (is (map? m) "m is not a map!") user/get-key (form-init8401797809408331100.clj:1) This is great for repl use, but it does side-effect (the printed error) and doesn't return anything structured. It's suited to development-time human use rather than runtime or machine-use. I see the potential for a macro which rethrows the assertion errors as something like ex-info exceptions (i.e. something with structured data.) That would fill runtime or machine-uses better (or structured logging?), but I'm not sure that fits with the spirit of pre/post conditions in the first place. After all, these do raise Java AssertionErrors, which are not meant to be recoverable. On Tuesday, March 29, 2016 at 4:19:12 PM UTC-5, Alex Miller wrote: > > (zombie thread back from the dead... :) > > I think enhancements on :pre/:post are interesting. > > http://dev.clojure.org/jira/browse/CLJ-1817 seems like a good place to > work on this. > > > On Tuesday, March 29, 2016 at 4:02:25 PM UTC-5, Colin Taylor wrote: >> >> 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> >>> 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.