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.

Reply via email to